Junctions are one of several multicast strategies of PSYC. See also some old unfinished doc at http://www.psyced.org/junctions

<coyo> Junctions are like virtual leaf IRC servers, only virtual routes for a context.

This is the current practice for Junctions.


anyway.. fippo enters his local spiegel room, which then sends as follows:

:_source	psyc://fi.ve.symlynx.com/@spiegel
:_target	psyc://ve.symlynx.com/@spiegel

:_amount_members	0
_request_link
.

the slave (or junction) requests to be linked to the master.

:_source	psyc://fi.ve.symlynx.com/@spiegel
:_target	psyc://ve.symlynx.com/@spiegel
:_source_relay	psyc://fi.ve.symlynx.com/~fippo

:_location_host	localhost
:_nick	fippo
_request_enter_join
.

it also delivers the reason for the link, a user who'd like to enter the room. it is a configuration choice for junctions, whether enter requests must be sent to the master to take the decision, or if the slaves are allowed to decide by themselves.

<fippo> why not wait until we are linked? We could use net/queue* to accomplish that.

:_source	psyc://ve.symlynx.com/@spiegel
:_target	psyc://fi.ve.symlynx.com/@spiegel

:_silence	1
:_topic	Hier pushen wir den RSS-Feed von Spiegel Online
_notice_link
You are now linked
.

alright, the link is established. _silence is an intermediate quick way of passing a conference control information. don't get used to it.

:_source	psyc://ve.symlynx.com/@spiegel
:_context	psyc://ve.symlynx.com/@spiegel
:_source_relay	psyc://fi.ve.symlynx.com/@spiegel

:_nick_place	Spiegel
:_location_host	localhost
:_nick	fippo
_notice_place_enter_join
[_nick] enters [_nick_place].
.

the user is accepted and the world is informed about this fact. this is a misconfiguration really, because newsfeeds shouldn't tell anyone who's receiving it. also they shouldn't echo the user's _location_host to the whole context, that's a bug. ***TODO*** this message should not be issued, at least not in this configuration.

:_source	psyc://ve.symlynx.com/@spiegel
:_target	psyc://fi.ve.symlynx.com/~fippo
:_source_relay	psyc://fi.ve.symlynx.com/@spiegel

:_affiliation	member
:_nick_place	Spiegel
:_location_host	localhost
:_nick	fippo
:_control	_silent
_echo_place_enter_join
[_nick] enters [_nick_place].
.

<fippo> Dieser _echo_place_enter_join ist einfach invalide. Wie es imho gehen sollte:

:_source	psyc://ve.symlynx.com/@spiegel
:_target	psyc://fi.ve.symlynx.com/@spiegel
:_source_relay	psyc://fi.ve.symlynx.com/~fippo

:_affiliation	member
:_nick_place	Spiegel
:_location_host	localhost
:_nick	fippo
:_control	_silent
_echo_place_enter_join
[_nick] enters [_nick_place].
.

<fippo> Was der Raum dann umschreiben würde zu einem normalen _echo_place_enter.

<lynX> Du willst sagen das _echo darf nicht von anderswoher kommen? Gut, der slave muss wohl erfahren, dass der User reingelassen wird, aber dann ist ein _notice_place_enter an den Slave korrekter, welcher dann das _echo auslöst. Aber da scheint ja was fehlkonfiguriert zu sein.


<fippo> Was auch krude aussieht sind die Nachrichten selbst:

:_source	psyc://ve.symlynx.com/@spiegel
:_target	psyc://fi.ve.symlynx.com/~fippo

:_channel_title	SPIEGEL ONLINE
:_nick_place	Spiegel
:_news_headline	Neuwagen:  BMW und Mercedes verbessern Qualitätsimage in den USA
:_page_news	http://www.spiegel.de/auto/aktuell/0,1518,356581,00.html
:_time_place	1116505400
_notice_news_headline_rss
([_nick_place]News) [_news_headline]
[_page_news]
.

this is a news message traveling along the junctions network. the PSYC part of it looks fine, but the header is broken.

<fippo> Wieso schreibt die Junction das nicht um, so dass sie selbst als _source da steht?

<lynX> i don't think that's the way to go. according to the psyc principles of multicast the header should have neither _target nor _source but rather a _context containing the master name of the channel, psyc://ve.symlynx.com/@spiegel. ***TODO*** and then it should soon have a global _counter, so that a potential loss of packets can be detected and obtained from somewhere. if this is done the junctions could operate on a UDP basis.

<fippo> why should the context that the client gets to know be the name of the master channel? As a client, I neither know about the master channel nor do I care. I have joined the slave, not the master. If the master insists on sending me messages I will consider them to be unsolicited.

If you want the context to be the master, then the client must join the master. This means, the slave must intercept any message going to the master. Then junctions are much more similar to the context slave system, with slaves being programmable.