Hi,
On Dec 4, 2007, at 3:14 AM, 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.
You can bypass 1) if your server sends the internal roster ASAP, and
then forwards the external gateway roster as roster pushes.
Best regards,
--
HIId: Pedro Melo
SMTP: [EMAIL PROTECTED]
XMPP: [EMAIL PROTECTED]
