[Standards] pubsub/pep auto-creation

Pedro Melo melo at simplicidade.org
Wed Mar 28 21:53:56 UTC 2007


Hi,

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.

> 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