[Council] meeting log 2006-11-29, PEP

Ian Paterson ian.paterson at clientside.co.uk
Fri Dec 1 12:06:02 CST 2006

Ralph Meijer wrote:
> On Thu, 2006-11-30 at 09:48 +0000, Ian Paterson wrote:
>> Hi,
>> I'm +1 for PEP enabling multiple nodes under one namespace. This will be 
>> useful for some use cases (e.g. several blog feeds per person).
>> However, IMHO we *also* need to keep the possibility of well-known node 
>> names (and well-known item IDs). Well-known is good because it eliminates 
>> unnecessary discovery steps.
> Well, if you allow multiple nodes under one namespace, this doesn't
> work. There can be only one node at a well-known node, so you need to
> discover the node's identity to see if it is a leaf or collection.

Yes, although I was thinking that this would be specified (MUST) in the 
XEP that specifies the existance of the namespace (urn:xmpp:pubkeys).

>> Discovery is fine when users are browsing data. But for cases where the 
>> client already knows exactly what it needs, if it has to perform discovery 
>> steps before it can actually request the data then IMO that is bad:
>> 1. The need for asynchronus code goes against our simple client mantra
>> 2. Introduces delays (bad for users)
>> 3. More network traffic (especially if you need to disco#info multiple 
>> items)
>> [example]
> ad 1. Jabber is inherently asynchronous. Also people writing clients
> with a GUI need to write asynchronous code anyway. Although I know some
> implementations have large issues with this, I don't find it a very
> convincing argument to limit our protocol development.
> ad 2+3. I can agree there.
>> Another example might be if Peter sends me a signature and the fingerprint 
>> of his public key, but I have no copy of his public key, then it is easiest 
>> for me to make a straight request for the public key 
>> (node:'urn:xmpp:pubkeys', id='thefingerprint'). I can only do this if PEP 
>> allows the pubkeys XEP to specify well-known node names and item ID values.
>> Note: For these two example use cases we need to be able to persist more 
>> than one publish event. i.e. persist multiple items independently of when 
>> they were published. Do people think this requirement could be added to PEP?
> I suppose it could. I see that these use cases want to use PEP for
> storage, and not necessarily for its pubsub behavior. For the latter the
> actual node name is rarely important, but for the former the node is the
> primary entry point. We seem to be struggling for a way to merge the two
> behaviors into using one protocol.
> I have to think more about this.


>> Finally, can I please also get people's feedback on the idea for PEP and/or 
>> pubsub posted to the list on Nov 19th:
> As the particular node would only have be created once in the lifetime
> of the user account, I don't think we should do this.

Hmm, we already allow auto node creation for presence model nodes.

The requirement to allow auto node creation for whitelist model nodes 
came from a list discussion about replacing jabber:iq:private. Ideally 
we need a protocol that is as simple for implementors as 
jabber:iq:private but which allows change notifications to all connected 
resources (e.g. for synchronization of preferences between online 
clients). The same three arguments apply as for the disco steps above, 
although IIRC only point 1, the asynchronus (implementation complexity) 
objection, was raised on the list (I understand you don't count that one 
;-) ).

The current behaviour seems inefficient:
1. Check if node exists already. (round trip)
2. If it doesn't, create it. (optional round trip)
3. Publish item(s) (final round trip)

A single round trip would seem more simple, rapid and bandwidth-efficient.

> If you meant to do access control on item level, I tend to say feature
> creep.

That was not the intention.

- Ian

More information about the Council mailing list