[JDEV] Discussion of transports?
rob at cataclysm.cx
Tue Sep 23 20:52:12 CDT 2003
> 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
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?
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
Size: 189 bytes
Desc: Digital signature
More information about the JDev