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/
smime.p7s
Description: S/MIME Cryptographic Signature
