[Standards-JIG] XEP-0163: PEP updates
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.
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards