On 5 June 2010 19:58, Brian Cully <[email protected]> wrote: > On 5-Jun-2010, at 05:35, Guus der Kinderen wrote: > > Again, the gateway will initiate a session on Romeo's behalf to the legacy > domain. The legacy roster representation is obtained, which now includes > Juliet only. A typical gateway representation will send out a roster-add > suggestion for [email protected] to the XMPP client of > Romeo. As this item already exists on the XMPP roster, it is silently > ignored. Benvolio's representation however, is also still there. Unless the > gateway has either direct access to Romeo's XMPP roster, or obtains somehow > the delta of roster changes on the legacy domain since the last login that > the gateway did (both are unlikely), there's no way that the gateway can > determine that it should send out a Roster Item Deletion suggestion. Romeo's > XMPP roster will continue to include both: > > [email protected] > [email protected] > > Benvolio is still there, even though it was removed from the roster on the > legacy domain. > > > This is a general issue with roster item exchange, but soluble. We have our > roster item exchange component cache it's latest suggestions in a database > so it can detect deletions from the legacy service. IOW, our server > remembers that it once sent out adds for both legacyjuliet and > legacybenvolio. When romeo logs in again, it sees that only legacyjuliet is > in the current legacy roster, but that it previously suggested an add for > legacybenvolio, so now it should suggest a removal. > > -bjc >
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? - Guus
