[Standards] pubsub/pep auto-creation

Mridul mridul at sun.com
Thu Mar 29 05:00:50 UTC 2007

Hi Pedro,

Pedro Melo wrote:
> 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 am not sure if the protocol is right place to put in checks for broken 
clients unless there is broken in the protocol itself which allows for 
this to happen.

The problem that is being tried to be addressed here is present in many 
places in xmpp+xeps in one form or other. Like creation of a new public 
room in muc, modification of privacy list, etc. In a lot of cases, we 
have the pattern of 'retrieve, check, create/modify & configure' : and 
in all of these, we would end up with the same problem.
My impression is that we have been pragmatic in these cases.

In any of these cases, we could argue for a need for transaction.
An operation should be atomic, not necessarily a set of operations - 
when there is a need for a sequence of operations which need to be 
executed in an atomic context : that is pointing to the need for 
critical sections/transactions/etc.
We might as will get that right and not keep modifying each xep for 
working around this problem.

If tomorrow Chris does get around (hint hint ;-) ) to proposing 
xep-transactions, wont publish+configure mode be redundant ? Useful - 
maybe (less code, less specs to support in client/server), redundant ? 

>> 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.

Configure as private.
I dont think there is much we can do against errant clients.
Even with publish+configure, we could have clients going and modifying 
config to public (argument for arguments sake :-) ).
What I am trying to get at is, if the usecase for a node is for it to be 
private, I dont see why any client would go and set it to public - 
private settings, etc come under this.

On the contrary, geoloc, etc might be more appropriate usecase for 
configure+publish : one resource might want to treat the geoloc as 
private/whitelisted while other might want all roster entries to know.

>> 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.

No arguments against need for simplicirity. Simplicity is definitely 
something to strive for : but not necessarily by introducing another 
state into the protocol for a special case.

>> 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.

What I was trying to get at was that there could be a more likely need 
for configuration changes of this sort in a pubsub case than in pep case.
But then we can always come up with usecases for both I guess :-)

>> 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?)

Yep, 'not' was an editing bug :-P Thanks !

> 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.

I can think of usecases where publish+configure makes sense - but 
private settings : other than defending against bugs I cant think of 
anything else for justifying need here.
And for that particular case - as psa mentioned in some other thread : 
public shaming + filing bugs !

>> 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.

Yes, I do agree that it wont be a drop in replacement.
Unless it is auto-provisioned as part of user creation in some way and 
clients can always rely on this.

> 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.

Client code is going to be more verbose to use pep instead of 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?

They will be complex - but clients/components/servers which feel there 
is a need for it will use it.
This is a concern across xep's and I am sure we are going to hit this 
discussion in one form or the other repeatedly.
xep-trans will be a solution to a cross cutting concern and rest of the 
protocol will remain simpler by just delegating to it.

> 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.

We are special casing only for avoiding transactions ?
That does not feel like the right thing to do - and how long will we 
keep avoinding it in one form or the other ?
And what will happen to these special cases as soon as xep-trans does 
come around : wont they not be redundant ?
Ofcourse unless we feel we cant/wont get trans right for xmpp. (separate 
and possibly very long discussion ;-) )


> 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