[jdev] XEP-0100 and roster/legacy contact list sync
stpeter at stpeter.im
Tue Dec 4 21:51:26 CST 2007
Massimiliano Mirra wrote:
> Thanks everyone for your insights. I finally settled on allowing the
> component to perform roster manipulation on its own. It doesn't
> modify the server-stored roster, rather the server forwards roster
> queries to a transport depending on the domain part of the "jid"
> attribute contained in <item> elements. For example, when the client
> <iq type='set' to='server.com' id='rost01'>
> <query xmlns='jabber:iq:roster'>
> <item jid='foo at transport.server.com'/>
> Server forwards it to transport.server.com, transport.server.com saves
> it in its roster and, if necessary, changes remote contact list
> accordingly. Upon roster request, server queries individual
> transports for roster fragments belonging to users, and merges them
> with its reply.
> Obviously this means that 1) roster retrieval is delayed by login to
> remote services, 2) server can only brute-query local transports,
> unless it inspects user's roster and finds the transports via disco
> (my implementation hasn't). My use case is very ad-hoc and limited,
> so this limitations are acceptable.
> I thought such forwarding of roster actions to be somewhat innovative,
> but of course it turns out it's been already described and in a better
> way: http://antecipate.blogspot.com/2006/06/roster-remoting.html
> I'm curious as to whether this has been considered by transport and
> server authors. The fact that it's transparent to the client looks
I like that this is:
1. transparent to the client
2. a matter for the server and transport
We might want to write this up in a spec at some point, for example to
document some of the error handling (what if the user is not registered
with the gateway, etc.).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the JDev