[Standards] pubsub/pep auto-creation

Pedro Melo melo at simplicidade.org
Wed Mar 28 22:38:23 UTC 2007


Hi,

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  
> privacy.
>
>> 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  
the XEP.

(thanks ian)

>> Need for publish+configure in pubsub makes sense where you might  
>> want to enforce it on arbitrary nodes where you have multiple  
>> publishers.
>
> 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  
> item.
>
> 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.
>

best regards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
Jabber ID: melo at simplicidade.org
Use Jabber!





More information about the Standards mailing list