[Standards] Syncing legacy contact list
Guus der Kinderen
guus.der.kinderen at gmail.com
Sun Jun 6 20:22:58 UTC 2010
On 6 June 2010 11:51, Dave Cridland <dave at 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
>> 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?
> 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
> 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 Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net<xmpp%3Adwd at dave.cridland.net>
> - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
> - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards