Hi, On Fri, Jan 22, 2010 at 8:23 AM, Jason Eacott <ja...@hardlight.com.au> wrote: > I sense more than a small amount of nastiness here, and I dont think its > warranted. > I know I'm not alone in thinking this particular issue is an important > missing capability of xmpp, but if nobody's interested in the discussion > then I'll drop it.
If my answer came off as nasty, it was not my intention. I do believe that the only sane way to have XMPP-based services grow in usefulness is if we get a way to access, in a controlled fashion, to user data (roster, private storage, PIP nodes, presence information). I think the OAuth model is something that would work for the "get an access token"-part. I'm not sure how much or how little we should standardize the way that the "what can you do with it"-part is done though. This is not a new problem, and I've been paying attention to a lot of proposals over the years. 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. 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. 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. Bye, -- Pedro Melo http://www.simplicidade.org/ xmpp:m...@simplicidade.org mailto:m...@simplicidade.org
