On Thu, Sep 17, 2009 at 9:14 AM, Pedro Melo <[email protected]> wrote: > Hi,
> No. I would need to check the previous versions but I *almost* certain that > XEP-0030 disco-publish feature was created to help clients deal with the > initial storm of disco#info requests. Basically, a client would publish his > disco#info information to the server, and from then on, any requests for > that information from other clients would be replied by the server, and not > the client. > Like a HTTP proxy cache, with the twist that the HTTP server would push the > latest version of the document to the proxy. > > Others might know the true reason for that part of the spec, I can only > speculate. Maybe it was written to solve the initial thundering herd of > disco#info requests from everybody on your roster when you log in. Right > now, I think the latest XEP-0115 (after we solve the pre-image attacks) is a > better solution. > Well this is good for di...@info, but what about disco#items? Publishing new items to pubsub nodes seems reasonable to me, since it would allow caching that information in the client (for example we do extensive use of ad hoc commands in our client and it would be nice to be able to cache that information an be notified only when it's changed). Since the distribution of disco#items follows a pattern where there is only one publisher some like PEP could be ideal. (there is just the problem that with many services like muc you don't have presence subscriptions) > In anyway, for your use case, these are not the droids you are looking for. > > I would stick with pubsub: a lot of people are working on it, so you will > probably find more good quality code for the server-side components. +1 -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: [email protected]
