[JDEV] Discussion of transports?

[Robert Norris]

> Actually, this was the feature that got me thinking in the first
> place.  Importing a contact is unlike creating a new contact in a lot
> of ways.  Besides the points already made, lots of information can
> come with an imported contact.
> 
> For example, MSN supports group of contacts.  At the very least, it
> would be nice to send group information along with the
> subscribe/import/whatever request for the client to consider.

Andrew and I have been discussing this in jdev today. It does seem like
there is value in having components able to manipulate rosters in a
limited fashion, to properly synchronise between remote and local
servers.

I've been thinking about allowing (with certain restrictions) entities
to set and get a users roster. This (by itself) would require no client
changes. Basically, a transport could do normal roster get/set
operations (just like a client), except that they would send requests to
the JID of the user that they want to change.

When this happened, the users server would issue a roster push to any
currently attached clients, so everyone stays up to date.

Problems with this:

 - It allows transports to override the normal Jabber roster semantics.
   This may or may not be desirable, depending on your point of view -
   one one hand, its bad because this is Jabber, and Jabber should work
   like Jabber, but on the other hand, I'm using a remote IM system, and
   I want it to perform the way it does.
 
 - Suitable access controls are required. Obviously, it won't do to
   allow anyone to change anyone elses roster. One thought we had is to
   restrict operations based on the transport JID (domain) - ie, the
   transport can only set roster items of its own users, and when a
   roster is retrieved, it only receives items for its own users.
   This may not be a good idea, however, as not all servers are
   transports - do I really want a remote (Jabber) server to be able to
   modify the contacts on my roster for its own users?
 
 - It seems that some sort of opt-in mechanism is required, whereby
   users can authorise certain remote entities to modify their roster.
   However, this requires client support, unless someone can think of
   something better (one hackish idea we had was to make it based on
   whether or not you've subscribed to a server (domain only) - if you
   have, then they can play).
 
 - Need a way for the server to know to push roster changes to the
   transport. If there is some list of "trusted" servers (like the
   opt-in list above), then this is easy, just use that. If not, then
   something else its needed.

So, there it is. Its an idea, and not a particularly well formed one. It
may not be worth the effort, I don't know. However, it does seem that to
tightly couple both local and remote rosters (which is needed to make
the remote service look less like a wart on the Jabber network), that
transports really do need some kind of access to a users roster.

So put your brains to work - should this happen? How should it work?

Rob.

-- 
Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://www.jabber.org/jdev/attachments/20030924/f479e5d8/attachment-0002.pgp>