On 6 June 2010 11:51, Dave Cridland <d...@cridland.net> wrote: > On Sat Jun 5 20:23:05 2010, Guus der Kinderen wrote: > >> That would work indeed. I'm not thrilled by the prospect of having to >> duplicate all legacy rosters in local persistent storage, but at least >> this >> way, we can make the XEPs work properly. >> >> Should the XEP suggest how roster syncing should take place in more detail >> than it does now? >> > > No. > > Many years ago, before the dawn of time - okay, last summer - there was > much enthusiastic discussion, as I recall, about the concept of a remote > roster. > > What this would do, in effect, is allow a remote fan-out of presence to a > distinct roster membership, and that roster would be owned by the remote > entity, and managed by it. > > So, gateways would operate by "owning" the legacy contacts in the roster, > and effectively the client treats it as a "sub-roster", incorporating it > into the local display. Even cleverererer, the client can cache it using > XEP-0237, manipulate it using RFC 3921 core commands, and really, the only > "special" thing is that you'd have to send the controlling entity presence > in order to have presence sent onward to those contacts. Of course, by > placing the remote entity in your local server roster - the one you have now > - this would happen anyway when you send presnece to *that* controlling > entity - ie, your account, in your broadcast presence. > > The entire sync issue then goes away, I think, and the interaction between > client, server, and gateway looks a whole heap simpler to my eyes. > > My understanding is that at least some client and gateway developers are > interested in playing about with some experimental code to see how this > works out in practise, but it all sounds sane to me. > > One interesting case is where the remote roster is not a gateway as such, > simply an ordinary XMPP account that you've been granted access to, perhaps > because you own them both... > > I was no witness to the rejoice that apparently happened many moons ago, but I like the idea that you're base lining here. The downside is that to get it working, a lot of redesign and implementation needs to happen.
Although I'm not opposing that, I would like to see the current XEPs being fixed/improved in a way that doesn't require structural changes. I think the suggestions made by both Brian and myself will make the existing XEPs "work" as intended, without changing them in a structural way. Low-hanging fruits? Can we simple pick one (or another alternative to the same extend), incorporate that as a guideline in the existing XEPs, and continue work on the sub-roster idea in a parallel effort? Dave. > -- > Dave Cridland - mailto:d...@cridland.net - > xmpp:d...@dave.cridland.net<xmpp%3a...@dave.cridland.net> > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >
