On 5/4/06, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
We've never messed with rosters at all. Plenty of people would like to do fun, even magical things with rosters (annotations and all the rest) but the necessary changes have never been rolled into the core roster functionality. The beautiful optimization you suggest here could be offered by servers in a separate namespace so I don't have any strong objections to it. I'm not sure how much demand there really is for this feature, but server and client developers could experiment and see if it makes life much better for all concerned. :-)
(some blurb first, skip down if you want the comment related to the previous post) There have been some ideas thrown in my direction by a friend about creating a jabber-2-jabber transport that would function as a sort of hatrack (hatrack = Hyper Availability TRAnsport Connection Kit) - basically it's a transport where you can register all your other jid's so you only have to login to your main server, with your primary jid, and all the other accounts come online automagically. In other words, clients that don't support multiple jid's get it for free, via the transport. Now there are a few extra considerations here, the primary one being, how do you sync your rosters? Typically transports are used to connect to *legacy* networks. Some of these have the concept of 'groups', so JEP's like 0144 (Roster Item Exchange - rosterx) were created. As it happens the JEP only gives examples of legacy --> xmpp contact information. It doesn't explicitly cater for communicating the group changes *back* to the transport. So for example if someone registers with a transport (msn,aim,icq, afaik yahoo is the only one that implements rosterx), and gets their groups via rosterx (if they're lucky that their client support is) - the group information only flows: legacy --> xmpp. If they change the group the contact is a member of, then the legacy network doesn't here about it. (Should it? - that's surely up to the user to decide, but atm we can't tell the legacy network in any way). This becomes more obvious with the jabber-transport, xmpp-transport, hatrack (what ever you want to call it), because there are xmpp semantics on _both_ sides. Now obviously rosterx could be extended to handle group information flow back to the transport (if the user so desires, and the transport can handle it), but: USEFUL IDEAS: Rosterx can be used to support incremental /local/ roster updates too! You still need the magic opaque integer (dns does this to remember) but the list of changes could be sent in rosterx format. (provides add,remove,update - remove the from address, and it defaults to the server, brilliant) So combine JEP-0150 with JEP-0144! i.e. When server receives iq/query/jabber:iq:roster, with If-None-Match shim. then query client disco#info for rosterx, and if it supports it then deliver rosterx messages, otherwise spam roster. (an alternative would be to put a rosterx tag into the iq/query/jabber:iq:roster - yuck) -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
