[Standards-JIG] XEP-0163: PEP updates

Peter Saint-Andre stpeter at jabber.org
Wed Jan 3 03:19:24 UTC 2007

Remko Tronçon wrote:
>> Feedback is welcome as always.
> Removing the one-to-one mapping introduces some problems again that
> made us introduce PEP in the first place. How is a client supposed to
> determine to what node it should send node information ? If every
> client starts making his own nodes, won't there be a large resource
> overhead ? What happens with notifications: does the service send
> 'last published tune' events from all your nodes, or does it select a
> node ? If it selects a node, how does it select one ? What if one
> resource decides to publish http://jabber.org/protocol/tune
> information to the 'tune' node, and another resource decides to
> publish http://myserver.com/tune information to that same node, won't
> that conflict ?
> I realize that hardcoding the namespace in the pubsub node might not
> be in line with the pubsub spec, but i'm affraid we will be putting
> burden on the client again (i.e. choosing or finding out a node name
> to publish to). What is wrong with a one-to-one mapping ? Isn't
> multiple items per node enough to solve the issues that made you
> decide to go one-to-many again ?

Well, I'm not yet totally convinced that the one-to-one mapping is truly 
evil. :-) You raise some good points. The concern people have is that 
you might legitimately need or want to have multiple nodes that serve up 
the same kind of payload. The motivating example here is public keys 
(see XEP-0189), since you might have RSA keys, DSA keys, X.509 certs, 
etc. But the same reasoning might apply to things like blog feeds.

Now there are two possible responses:

1. If your data feeds are that complicated, just use pubsub.

2. Let's modify PEP in some way to support the desired complexity.

I like the simplicity of PEP. The whole point of PEP is simplicity (and 
if the full power of pubsub is not available, so be it). If we make PEP 
more complex, then it becomes unnecessary. At the same time, I like some 
of the ideas that Ian Paterson and I discussed recently -- especially 
some way to pre-define parameters for certain NodeIDs (so that we can 
"hardcode" that a NodeID of "storage:bookmarks" has a whitelist access 
model, for example). We may be able to do that with a registry, or there 
may be other approaches that would work.

One idea that Joe Hildebrand and I discussed today was a generic way for 
a pubsub node to point to other nodes. So let's say you post to five 
different blogs and you want to have a feed for each. Your "user 
blogging" NodeID could provide a pointer to all of your feeds, and 
interested users could follow those pointers to your real feeds. This is 
potentially confusing for clients (both publishers and subscribers) that 
don't support pointers, because now the payload is not a blog feed but 
just a pointer. Alternatively this would be a node configuration that 
the publisher would set, and subscription requests would be rejected 
with an error and a list of pointer nodes (go here and here and here if 
you want to subscribe to my bloggy feeds).

Another option is to have a filtering mechanism of some kind (the good 
folks at pubsub.com used to have such a mechanism). If I care about only 
two of your blogs, I could ask your PEP service to send me only data 
from those two even if I'm subscribed only to your one "user blogging" 
node (no pointers here, just the raw feed). Naturally that might be of 
interest for pubsub in general, too. It's not simple like PEP, and it's 
a pubsub extension that we'd need to define, but it might do the job. 
One potential problem is: would the PEP service (and the subscriber) 
need to know something about the semantics of the payload type in order 
to provide such filtering? It seems to me it might.

In summary, I am loath to give up the simplicity of PEP, but I want to 
make sure we can solve the problems that people want to solve without 
too many epicycles. Pointers and filtering feel a bit epicyclic to me, 
but on the other hand they might be generically useful.



Peter Saint-Andre
Jabber Software Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070102/538d4b3c/attachment.bin>

More information about the Standards mailing list