[Standards] pubsub/pep auto-creation
melo at simplicidade.org
Wed Mar 28 22:38:23 UTC 2007
Just clarifying some things.
On Mar 28, 2007, at 10:53 PM, Pedro Melo wrote:
> On Mar 28, 2007, at 8:52 PM, Mridul wrote:
>> 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 think client authors want a more simple way to guarantee proper
> node configuration in the presence of un-cooperating clients.
>> 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.
> I would say the exact opposite given that pep, by providing more
> personal data on the general case, needs more strict assurances of
>> It might make sense to just push it to pubsub and leave pep simple.
> Yes, keeping it simple is one of the reasons to suggest publish
> +configure. I haven't seen nobody dispute that, on the wire, publish
> +configure is more complex than the alternatives currently in the XEP.
err :) I meant: "I haven't seen nobody dispute that, on the wire,
publish+configure is more simple than the alternatives currently in
>> Need for publish+configure in pubsub makes sense where you might
>> want to enforce it on arbitrary nodes where you have multiple
> Which is the scenario for PEP in the case of multiple resources.
>> PEP was supposed to be more simpler and scaled down & specific to
>> a user - used primarily for user specific eventing and data.
> Which is orthogonal to the existence of multiple publishers.
>> 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.
> Ahhs, there lies the trap. "no client is (not) going to make it
> public" (i'm not a native speaker but I believe the "not" changes
> what you meant?)
> the issue that all the client authors are making is that we just
> don't trust each other :). joke aside, is not that we don't trust
> each other. I think the point is that with publish+configure we
> just don't have to, and if a bad written client or a rogue client
> or whatever else comes along, the possibility of his behavior
> affecting my client behavior is nil with publish+configure.
>> So it already enables drop in replacement to private settings.
> No it does not, because with private setting right now, you just
> send an iq set and wait for a reply. That's it.
> On the other hand, a client with the current PEP must retrieve the
> node configuration to make sure if it's correctly configured as
> private. If that fails because the node does not exist, he must
> create the node with the proper configuration and then publish the
> A little bit more complex than jabber:iq:private.
>> 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).
> I agree. The argument for transactions is minor for us, but you
> can't argue that it exists, and that publish+configure would solve
> even that for people/clients that could benefit from that assurance...
>> 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.
> That would make it more complex, right?
> On the other hand, publish+configure solves the transactional
> problem (for those who need that sort of thing) and it even simpler
> than current XEP versions.
Jabber ID: melo at simplicidade.org
More information about the Standards