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

Peter Saint-Andre stpeter at stpeter.im
Fri Jan 22 14:15:34 UTC 2010


On 1/22/10 4:08 AM, Pedro Melo wrote:

> I do think that the usual mantra "simple clients, complex servers" is
> limiting our current growth in terms of features because the major
> XMPP services will not update their servers just because it has cool
> new features. Specifically, I don't see GTalk implementing some of the
> features that just to tick the XEP-NNNN box.

We pay lip service to that mantra, but in reality servers haven't done
anything on behalf of clients since the roster protocol was designed
(well, maybe private XML storage) and in fact I would say that servers
have mostly become dumb XML routers. Whether that is good or bad is open
to debate.

> So I think we should put a little bit more logic on the client side in
> future protocols. It would allow us to deploy more advanced
> functionality without having to way for servers. I think that servers
> should gain protocols that have multiple purposes, so reuse PubSub or
> even current MUC for future protocols.

That does seem quite logical, and I think we've tried to move more in
that direction over time. But here again something like pubsub is
payload-agnostic and doesn't have a lot of smarts, which need to be
designed into the application that you build on top of pubsub.

> Even access to private data can be implemented in the client, acting
> as the proxy and validator for other entities requests. The drawback
> is that you need at least one resource with that capability online.

Right, and that's a bottleneck.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- 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/20100122/9670ee4b/attachment.bin>


More information about the Standards mailing list