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.