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 > sends: > > <iq type='set' to='server.com' id='rost01'> > <query xmlns='jabber:iq:roster'> > <item jid='[EMAIL PROTECTED]'/> > </query> > <iq> > > 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 > attractive.
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.). Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
