[Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
paulrw at codian.com
Thu Jan 21 11:14:48 UTC 2010
Peter Saint-Andre wrote:
> Back before we even developed Jingle, I had some similar thoughts. It
> would be great if I could ask my server to call you (like a switchboard
> operator in the olden days), but realistically sometimes the client does
> know best (it's behind a firewall, it has certain network interfaces, it
> has certain capabilities, etc.). I do think it's worth exploring how
> much servers can do, because in many ways we've gotten away from the
> philosophy of "simple clients, complex servers". Is that philosophy
> really valid and sustainable? Should servers really do more, or should
> they be XML routers in the middle? Should the network be smart or dumb?
> These are large design questions and I don't think they have easy answers.
As I think I talked to a few people about in Brussels last year, I'm
very interested in working on how we can put more call-control
intelligence into the server. It's not a simple case of "server knows
best" or "client knows best": the server is better placed to know what
resources people have online, and can do neat things like enabling a
call to someone whose presence you haven't subscribed to without
necessarily leaking their presence. On the other hand, the client knows
what codecs it has, what network interfaces it has available, and how it
might be possible to contact them through ICE.
So I'm strongly in favour of a hybrid approach. Like with sending
messages, you can initiate a Jingle session (like a chat session) to the
bare JID; this is handled by the server, which then uses its knowledge
of the far end's presence to route the initiate session to the
appropriate resources. Only when the far end gives a positive response
does the caller get a full JID with which to communicate, and at this
point the server no longer needs to be in the loop for messages.
More information about the Standards