[Standards-JIG] proto-JEP: Smart Presence Distribution
Carlo v. Loesch
CvL at mail.symlynX.com
Wed May 17 20:24:14 UTC 2006
Richard Dobson typeth:
| Sorry maybe I didnt make it clear, I pointed out JEP-0033 as an example
| of a multicasting mechanism to start from that would actually work
| without breaking anything, as JEP-0033 requires that you send the
i would like to emphasize that by the original meaning of multicast,
JEP-0033 is not a multicast, it is a more verbose type of "smart unicast"
or maybe you want to call it a one-hop-cast.
let's imagine you have a dozen friends in argentina and a couple of
friends in mexico. real multicast would let you send one message
to mexico, where it is distributed further to mexican servers,
then forward the message to argentina, where it is distributed further.
multicast is a spanning tree like the mbone or even a redundant network.
JEP-0033 only sends the message to mexico. all the argentinians have
to get it from there.
not that this were bad, our JEP is not doing any better (not until we
have published the follow-up JEP on multicasting, which extends the
functionality of this one)
but by strict definition the word 'multicast' is incorrect in JEP-0033.
| would use lots of bandwidth and not save you much. What I suggest that
| we do is extend JEP-0033 with a mechanism for pre-negotiating an address
| list with the multicasting component that can be re-used without needing
| to send that address list inside each stanza that you want to relay,
| thus saving lots of bytes, but without breaking privacy lists.
yes, this too is a way to get to the same result. only i believe we can
achieve this using the existing data structures and subscription protocols.
we don't have to add a whole layer on top of it.
| be determined protocol which is represented by its own JID, and any
| <presence from='romeo at montague/inlove' to='s4134edd at multicast.capulet'/>
oh i love jid hacks :)
if jid were defined as a url, one could encode things nicer,
but huh that's another story.
| This all works without breaking privacy lists and without requiring the
| rosters to be in sync.
okay, i'll pick another posting to reply to, and write down how we
can keep privacy lists and rosters, and don't need this extra protocol.
More information about the Standards