[Standards-JIG] Roster Subscription Synchronisation
richard at dobson-i.net
Thu Sep 16 08:41:32 UTC 2004
>> It might be sheer luck but if all the legacy services work this way,
>> no one has yet tried to disprove then it is a perfectly logical thing to
>> do, as far as I can see it if the contact is in the legacy roster at all
>> the subscription will be something other than "none", and will only
>> a subscription of "none" when it is somehow removed from that legacy
>> as well as no longer being subscribed by the other side, so you might as
>> well then use this as a way of cleaning out the possible "ghost"
>> I would think even for normal jabber users clients should really be
>> prompting if they arnt already when a contact goes to "none" if they want
>> it removed, since it is of no real use to them anymore at this point,
>> "to" status contacts should probably be being hidden from the main
>> display by default and either shown on request or shown in a way similar
>> how msn shows its allowed list.
> So what are you saying? That I'm not _allowed_ to transport Jabber to
> and get the convenience of roster synchronisation between my host Jabber
> server and the remote Jabber server?
Course not, just questioning of how much use it will really be, as far as I
can see not many people are likely to take advantage of that, but a simple
solution since its client side stuff anyway would be to use the info you
will have already got from the transport when discoing it to determine what
type of transport it is (i.e. MSN, Yahoo, AIM or ICQ) and then implement the
bit of delete logic I described, but anyway, now since roster subsync has
been rejected not much point arguing about stuff like this (we will just end
up getting frustrated) as im sure Peter will create something that solves
all this stuff and we will all be far more happier with the result.
>> Yes this is the ideal solution that a server based sync system does all
>> this stuff all automatically for the user once they have authorised it to
>> do so, but the people involved with this spec want something now and do
>> want to wait for what even they admit is the better approach of a server
>> based solution.
> We agree here, at least.
> The way I see it right now, even if it were implemented as a client thing,
> wait won't go away. Whereas the bleeding edge clients will get the fix
> soon, users on the clients who aren't so daring will still have to wait
> to get the feature, and those users will continue to complain about the
> problem until every client in existence has implemented the change.
> If it were done purely on the server side, only a few servers would need
> code (along with the transports, naturally,) and it should have a greater
> payoff, earlier.
Yup I quite agree here, infact this is something along the lines of what I
said earlier in the discussion but the people concerned didnt seem to take
any notice as they seemed to be dead set on their spec at all costs.
More information about the Standards