> 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: [EMAIL PROTECTED] Web: http://cataclysm.cx/
signature.asc
Description: Digital signature
