[jdev] Proposal for a solution to transport rosters

[maqi at jabberstudio.org]

On Sat, 4 Sep 2004, Justin Karneges wrote:

> In each solution, it's going to take either an upgrade of clients and
> transports, or an upgrade of servers and transports.  Normally anything
> that requires a server upgrade is considered difficult (which is
> unfortunate, because sometimes it is the right way)

I think it's not "sometimes" the right way, it's about *always* the right
way. It's very unfortunate that currently most server implementations are
more or less frozen - any major update is almost impossible as there are
stability problems or other "more urgent" issues.

> however in this case it might actually be easier, since the admin must
> already go out of his way on the server-side because he has to upgrade
> his transports.

Nobody's forced to upgrade his transports if we go James' way. And, of
course, for example upgrading PyMSN-t (which is done in some seconds as
all is needed is replacing some .py files) is WAY easier than upgrading
jabberd14/jabberd2/whatever.

> This is one of those rare situations where upgrading the server side is
> likely the easier path.

Right now, we would need to quickly invent a protocol to implement Shared
Roster Groups. This would also need some kind of s2s authentication/
permissions protocol. This needs time. Of course, one can quickly think of
a simplified way to implement Shared Groups ("any subscribed JID without a
username part may change our roster"), but this is clearly a hack and
doesn't cover the amount of interesting use cases that could be covered
with a more elaborated approach (see my RDF idea).

So I'd really like to have some quick, simple, and backwards/
upwards-compatible solution which James' proposal seems to be. For now.

Regards