[Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]

Peter Saint-Andre stpeter at stpeter.im
Thu Jan 21 05:53:35 UTC 2010

On 1/20/10 8:01 PM, Matthew Wild wrote:
> 2010/1/21 Jason Eacott <jason at hardlight.com.au>:
>> Matthew Wild wrote:
>> ...
>>> Downsides are that this requires server support, especially thinking
>>> of e.g. gmail.com here. Probably other things I'm missing too.
>> again this just makes me sure that XMPP as it stands is far too client
>> centric, and needs to become properly extensible from the serverside too.
>> there should be a way for server extensions to do what clients can.
>> (I know thats not what you were suggesting here, but it might make
>> implementing such things easier)
> I didn't want to divert the original thread before it even starts, but
> was curious - what do you mean by this? I don't see how XMPP can
> enforce Google to implement any extension. The issue here is that the
> predominant use case for decloaking is Jingle, and many Jingle users
> happen to be Google Talk users.
> If decloaking was done client-side then the user can simply switch to
> a better client that supports it, switching server is much harder
> work.
> I guess I just don't understand your "there should be a way for server
> extensions to do what clients can".

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.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100120/ff189563/attachment.bin>

More information about the Standards mailing list