[Standards] Proposed XMPP Extension: Metacontacts

Mridul Muralidharan mridul at sun.com
Tue May 8 18:25:54 UTC 2007

Hi Ian,

   Please see below.


PS : My client messed up and I did not see this until now, apologies for 
late response.

Ian Paterson wrote:
> Mridul wrote:
>> Yes, this is indeed a problem - especially for the well known namespaces
>> like bookmarks, etc which clients sometimes expect to be in sync.
>> We have faced this issue in the past too w.r.t conference bookmarks.
> I'm glad to hear we're fixing a real world problem.
>>> PEP also allows multiple items to be published to the same node
>>> (namespace) and then updated individually. Whereas, with iq:private,
>>> updating a small part of the data associated with a namespace requires
>>> *all* the data to be read, edited and then completely rewritten!
>> Use different namespaces with a namespace hierarchy ?
>> I am not sure why we need to put disjoint data within same namespace.
> Well, what if there are a lot of small items, and I want to fetch all of 
> them. If I give each item it's own iq:private namespace then I will have 
> to generate many requests/response pairs to receive all the items. And 
> how do I know the names of the namespaces (i.e. which items are 
> available in cases where the names of the items are not well known)? We 
> had to implement this once already, the only way was to save an index in 
> a "well known" (for our client) iq:private namespace, read the index, 
> and then read the data with multiple item namespace requests. This was 
> very nasty, but we had no choice. PEP will solve that.

Yes, this does look painful - looks like I did not think it through ... 
definitely forgot my earlier line of thought !

>>> PEP also gives us a registry of well known nodes.
>> private data is going to be specific to a application in most cases.
>> So I am not sure why we would need this ...
>> Typically pref's for gaim would not be useful for sun im
>> client/exodus/psi/etc.
>> The data which is going to be reusable is already standardized (or could
>> be) like bookmarks, etc.
> Yes, this is only a subtle advantage. I think XEP authors will leverage 
> PEP much more than they have employed iq:private. Personally I feel the 
> existance of a node registry helps encourage that. IIRC there is no one 
> place where you can discover which iq:private namespaces have been 
> reserved. That has left us all with the (incorrect?) feeling that 
> iq:private is intended mainly for proprietary use (as you pointed out).

There will still be a need for proprietary use - and for use where 
client just 'dumps some data' on server for later retrieval/use.
Usecases like this do not benefit from pep and the current private 
storage is ideal for these.
Remodeling private storage around private storage will just add 
additional complexity without any benefit ... but there are extensions 
built on top of private storage which do benefit - like bookmarks imo.


> - Ian

More information about the Standards mailing list