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

Ralph Meijer jabberfoundation at ralphm.ik.nu
Thu Nov 30 05:13:40 CST 2006


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.

> 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.

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

-- 
Groetjes,

ralphm
-- 
Groetjes,

ralphm



More information about the Council mailing list