On Fri, Aug 03, 2007 at 11:30:05AM +0200, Tomasz Sterna wrote: > Dnia 03-08-2007, pią o godzinie 11:10 +0200, Robin Redeker napisał(a): > > Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html ? > > Hmm... I had always found this JEP awkward. > We have roster to store these kinds of things. > Early versions of jabberd/2 allowed storing an <x/> element with the > roster item, that clients could store the additional item information. > But it was explicitly forbidden by Standards JIG, thus removing support, > which in turn resulted in JEP-0048.
Just some random thoughts here... I also find XEP-0048 a bit awkward, but the limitation of the roster for presence subscriptions seems to let no room for other informations stored there. See also http://www.xmpp.org/extensions/xep-0083.html (Nested Roster Groups) which I find equally awkward! See also http://www.xmpp.org/extensions/xep-0057.html, which is probably what you meant with storing additional <x> elements with the roster. Also interesting is the way tkabber stores notes for roster items: <iq id='19' type='set' xml:lang='en-US'> <query xmlns='jabber:iq:private'> <storage xmlns='storage:rosternotes'> <note jid='[EMAIL PROTECTED]' cdate='2007-08-04T10:32:54Z' mdate='2007-08-04T10:32:54Z'>test</note> <note jid='[EMAIL PROTECTED]' cdate='2007-08-04T10:34:26Z' mdate='2007-08-04T10:34:26Z'>fwfwefew</note> </storage> </query> </iq> Private XML storage is IMO a good solution for that. But I've not seen any XEP for this kind of note storage (maybe I just couldn't find it). Applications have to sync the roster with other places where information for that JID is stored. I also miss a registrar for this kind of usage of private XML storage. Also note that the private XML storage will become more and more messy with the number of different programs storing information there. Does a way exist to purge all information in the XML storage? Or even list the stored information? Listing stored information would allow the removal of unknown elements by clients. > > That works (see below) but there is a more pressing problem here: > > [...] > > This is why I asked, to hear others feedback and issues. > Could we use standard roster for it, or we really have to stick with the > XEP-0048 defined alternative roster. Well, back to the issue: I would not like to join every MUC I have on my list just because I'm available. I would still like some MUCs only optionally joined and not automatically. How should that work? By unsubscribing from the MUC and not delete the roster item? Would work I guess. The problem here is XEP-0045 which defines the <x> element for MUC-ability-signalling. I see no issues in storing many other things in the roster, but I see issues with making that work with MUC the way MUC is defined (which I don't really like either, but can't tell yet why :-) Robin
