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.
--
Paul
