> Openfire allows this, and the gateways use jabber:iq:roster. It works > fine, but in order to use too roster sequencing I'd like to have a > centralized repository of the roster, and the best approach, if we > don't want to hack into the server, is to directly tell the client > what to do.
Openfire lets the components use jabber:iq:roster on a user's roster, but that involves quite a bit of trust on the component (as it has access to the full roster). I meant something different: - The client logs in - It gets presence from "gateway.example.com", which includes the "shared-roster" capability - It does a jabber:iq:roster request on gateway.example.com - It adds the resulting items to the *displayed* roster (not the master roster) - The gateway acts as a real server from now on: it sends presence, subscription requests, and roster pushes for all contacts in its roster to the client that requested the roster, and forwards presence to all contacts in the reverse direction. This will of course only work for clients supporting the protocol, but I don't think there's a clean other way that doesn't have too much trust or privacy issues. A component could check at registration time whether the client supports the protocol, and use the old ways if not. This would mean that the user needs to re-register if it switches to a client which does / does not support the protocol and wishes to use the gateway, but this should phase out eventually. cheers, Remko
