2009/7/14 Remko Tronçon <[email protected]>: >> Right, but I keep wondering if modifying XEP-0093 to include the second >> use case was wrong... > > It wasn't really a good flow, no. Psi implements this XEP too, and it > helps with the whole auth-storm-on-gateway-registration, but still has > quite some drawbacks. I think we should try defining a better protocol > for this.
Indeed psi still has the problem of storms, since after presenting the addition request it asks to authorize each presence subscription arriving from the gateway as an answer. However this is just an implementation issue easily fixable. > I liked the thought we had a few years ago where you could use > jabber:iq:roster on something else than a server JID (which was > prohibited by the RFC back then, I forgot if we did something about > that in bis). Remote rosters such as component rosters wouldn't need > to be mirrored in your real roster any more, which would solve quite a > bit of problems. Openfire allows this, and the gateways use jabber:iq:roster. It works fine, but in order to use too roster sequencing I'd like to have a centralized repository of the roster, and the best approach, if we don't want to hack into the server, is to directly tell the client what to do. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [email protected]
