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...
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
