[Standards] pubsub/pep auto-creation

Mridul mridul at sun.com
Wed Mar 28 19:52:54 UTC 2007


   Was following the council discussion on this : and I am still not 
very sure of the requirements and problems attempted to be solved here.

I do understand that there might be a set of usecases where you always 
want the config to be strictly what you wanted to publish the data with 
- but from what I see, this is going to be more relevant to pubsub and 
rarely (if ever) to pep.
It might make sense to just push it to pubsub and leave pep simple.
Need for publish+configure in pubsub makes sense where you might want to 
enforce it on arbitrary nodes where you have multiple publishers.
PEP was supposed to be more simpler and scaled down & specific to a user 
- used primarily for user specific eventing and data.

For example - if a node is expected to be private (like user's private 
settings or bookmarks) - it is going to remain private across resources 
: no client is not going to make it public.
So it already enables drop in replacement to private settings.

The argument for transactions can be used at a variety of places where 
shared data is modified : at user level (roster, privacy lists, private 
settings, bookmarks, etc), node level (muc/pubsub affiliations/config), 
at service level (commands to server/components) , etc. We do get along 
in a manner of speaking with optimistic locking in most cases (as 
implementation details).
The shared data modification problem mentioned is falling in same 
category (w.r.t locking). This is a more generic problem and not 
specific to pep.
If we are attempting to solve this class of problem, we might as well 
fix it properly : support transactions in xmpp and enable any xep which 
sets/modifies data to be used in its context.


Kevin Smith wrote:
> On 22 Mar 2007, at 11:01, Mridul wrote:
>> I dont understand the private data becoming public part - that is going
>> to happen whether you do publish + configure , or the alternative when
>> there are two different clients going to change configuration on the 
>> node.
> The problem is when you publish to a node with an unknown configuration, 
> not when you purposefully change the configuration of a node without 
> changing the data.
> If I sign in with client X and Y.
> Client X does first publish, checks it exists, it doesn't, creates it 
> etc, publishes to node, and sets public.
> Client Y does a publish of data it intends to be private, doesn't get an 
> error (node not found), so assumes everything is fine and dandy, when in 
> fact the node has already been created and set to a different 
> configuration.
> And this can happen every time you publish, that you need to check that 
> the node hasn't been configured in a different way (potentially since 
> you last checked the config and published).
> So the problem isn't that some other resource will come along later and 
> reveal something you've already published in private by changing the 
> config, but that they will change the config when they publish something 
> public on the node, and that you'll then 'not notice' when publishing 
> something private.
> /K
> --Kevin Smith
> Psi Jabber client developer/project leader (http://psi-im.org/)
> Postgraduate Research Student, Computer Science, University Of Exeter

More information about the Standards mailing list