[Standards] pubsub/pep auto-creation
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
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
> 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
> 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.
> --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