[Standards-JIG] XEP-0163: PEP updates

[Kevin Smith]

On 3 Jan 2007, at 03:19, Peter Saint-Andre wrote:
> Remko Tronçon wrote:
>>> Feedback is welcome as always.
>> Removing the one-to-one mapping introduces some problems
>> ...
>> 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
>> ...
>> Isn't
>> multiple items per node enough to solve the issues
>
> Well, I'm not yet totally convinced that the one-to-one mapping is  
> truly evil. :-)
It may not be truly evil, but it certainly penalises the simplicity,  
and I'm not sure yet that we gain anything by it.

> 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.
Multiple nodes with the same type of payload, or multiple items per  
node?

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

It seems to me that people would like everything to be shoehorned  
into PEP - why is this? Personal keys seem like they're probably  
reasonable to be PEPped, but blogging seems well outside that realm  
to me. This leads to an option three:
3. Work out why (some) people are keen to avoid pubsub, even for the  
'heavy stuff' like blogging, address that and leave PEP for the  
simple things.

> I like the simplicity of PEP. The whole point of PEP is simplicity.  
> If we make PEP more complex, then it becomes unnecessary.
Almost. If we make PEP more complex, it's still necessary (else we  
wouldn't be having the discussion in the first place) it'll just be  
unsuitable. We still need the simple option, and if PEP feature- 
creeps so it's no longer simple enough, we'll end up with yet another  
XEP trying to make a simple profile.

> I like ... some way to pre-define parameters for certain NodeIDs
I think this is orthogonal to the namespace/node discussion though?  
(On first glance this seems to be the kind of thing we want to  
encourage, sensible preset parameters).

> 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
Well, it's clear we can't solve all problems with PEP - pubsub was  
meant to solve all problems,  and is excessively complex for some  
uses, if we let PEP grow to solve all problems, it'll a) be too  
complex too, and b) be pubsub on a JID. If what people want is to  
always have pubsub on a JID, we should probably address that  
independently.

There are a lot of clients, and there are likely to be more in the  
future, covering various different use cases. I'm very keen that they  
should not need to have to cover 'complex' features like reading the  
local news for 8 continents and Mars simultaneously in order to be  
able to see a user's avatar.

/K

-- 
Kevin Smith
Psi XMPP Client Project Leader (http://psi-im.org)