[Standards-JIG] proto-JEP: Smart Presence Distribution
Carlo v. Loesch
CvL at mail.symlynX.com
Thu May 18 11:05:45 UTC 2006
Dave Cridland typeth:
| a) Worthwhile based on the cost of implementation. (Is this tricky to
| code right?)
no, it took us one hour because we already had the data structures
in the right place, so all we added was rendering and parsing of the
no-to syntax, and whoops it worked. we will have to retrofit it with
placebo-to-syntax now.. ;)
all you have to code is, when receiving such a packet, to walk through
your user list, pick out the ones that know the sender, and make sure
they have properly legally subscribed his presence. if this operation
is costy in your case, cache it. in our case we have such "context
receiver lists" for both presence and groupchat anyway, and they are
created as users login and join groups. in PSYC, presence, groupchat
and newscasters are all derivates of the abstract 'context' concept.
they use a common syntax for distribution, applicable to any message
type. in other words you can even send messages to your presence channel,
just like myspace bulletins. the /shout command delivers your message to
all of your friends using the same multicast context as for presence.
| b) Worthwhile based on the cost of deployment. (Is this going to cost
| CPU, memory, etc?)
this varies depending on the architecture of your server.
keeping a list of pointers to user objects per sender shouldn't
be a big issue.
| c) Worthwhile based on the detrimental effects to security. (Is this
| handing over responsibility for policy to a foerign domain?)
opinions on this vary a lot, as we have seen.
would be useful to have some facts and figures.
guess we can only find out by running a little
test network using this approach.
| d) Worthwhile to do now, or should we be concentrating on simpler
| methods first. (The "low hanging fruit" argument).
this is low hanging fruit. other approaches require more work.
| Any real-world compression algorithm will reduce the complete
| collection of jids by a significant amount because they're
| self-similar, containing a significant quantity of repetitive, and
| thus redundant, data. This is basic information theory stuff.
good, still everyone running a larger service agrees jabber has some
serious scalability issues. is compression already in place, or is
something keeping you from switching it on? i know our server supports
some, but i don't know if we are actually using it for xmpp.. fippo?
fippo is the man who wrote the jabber server in psyced, i'm just the
guy who comes up with the multicast ideas and the core of psyced. ;)
well compression is always appropriate with xml, so if it's not in
use yet, you should certainly start doing so, soon. our JEP will
then help reduce the traffic, if necessary. would compression also
solve all issues related to pubsub traffic?
| Of course, you shouldn't let the facts get in the way of an
| opportunity to express your undoubted wit.
well many of us here have this sort of glorious ability. :)
| By the way, I'd drop that sarcastic tone about the "placebo to", as
| well, because I'm not clear it's redundant in the case where several
| domains are hosted on the same server. Besides which, whatever the
in the current architecture of jabber a new tcp connection is created
for every domain a host has, and within that tcp connection the stream:to
says which hostname the communication is directed to. leaving out the
'to' would simply mean, that the 'stream:to' is intended.
| technical issues, logistically it's too difficult to remove in
i was told an update to XMPP is in the making anyway, so it okay
to suggest changes that would be reflected in a new RFC. but huh
it's just second hand information and i may be wrong.
well i don't care, i already added the redundant 'to' to the JEP.
| PS: It's not "typeth" - that's second person singular archaic. The
oh dear, i haven't known this in the past dozen years i use that
word in my replies.. ;)
More information about the Standards