[Standards] publish+configure again

[Peter Saint-Andre]

Peter Saint-Andre wrote:

>> * Client authors: would you send configuration forms every publish
>>   request?
> 
> Given that the presence access model is the required default for PEP 
> servers, I don't think it would be necessary to send the configuration 
> form for every publish. IMHO the presence access model is pretty 
> intuitive for users (if someone can see your presence, they can see your 
> mood/tune/etc.) so there's not much reason to mess with that.

I just chatted with someone about this via IM, but he didn't want to 
post to the list for fear of reprisals. ;-) Also I meant to mention 
something like this in my original mail but forgot.

If we keep auto-create (which seems very likely) then I think 
publish+configure makes sense if and only if the node will be 
auto-created on publish. No nasty error flows, it maps to IQ-set from 
iq:private, it's "fire and forget".

I think publish+configure makes a lot less sense if the node already 
exists. The argument that "I don't trust the other clients" seems 
wrongheaded to me. So does the argument that what I really want is 
per-item access control -- we don't have that in XEP-0060 and I see no 
good reason to add it to PEP.

Now the problem is that you don't know before publishing if the node 
exists, unless you check first (which requires more stanzas etc.). So it 
seems that developers will write their clients such that they always 
send publish+configure. This may be true even if the default access 
model is presence, since you never know if another client changed the 
access model to be something else. [Question: if you send publish 
without configure, does that mean you want (a) the default access model 
or (b) the existing access model even if it is not the default?]

Despite my earlier email, I now see three options, not two:

1. Get rid of auto-create. If the node does not exist on publish, the 
server shall return a not-found error, forcing the client to go through 
the full node-creation sequence.

2. Support publish+configure for all publishes. If the node does not 
exist on publish, the server shall create the node and apply the 
specified configuration. If the node already exists on publish, apply 
the specified configuration.

3. Support publish+configure only on first publish. If the node does not 
exist on publish, the server shall create the node and apply the 
specified configuration. If the node already exists on publish, the 
server shall publish the item only if the configure part of the 
publish+configure matches the existing node config, otherwise it shall 
return an error ("config-does-not-match") and the client must complete 
the normal flow for modifying the node config before the item can be 
published. This doesn't give you (the illusion of) per-item access 
control nor the ability to change the node config via publish, but it 
does give you fire-and-forget the first time around and it mostly [1] 
ensures that items are not published with undesirable access controls. 
Servers would need to check the config on publish+configure and return 
an error if they don't match. Clients would need to properly handle the 
config-does-not-match error case. Node configs are modified only by 
explicit node-configuration change (not implicitly via p+c).

Maybe this is the best of both worlds. Maybe it is the worst of both 
worlds. You decide.

/psa

[1] We still have the possibility of race conditions with #3 (resource 1 
modifies node configuration but resource 2 changes it back before 
resource 1 can publish with the new config), but we have ways of dealing 
with that if people really care -- as Ralph points out, look at Examples 
133 and 134 in XEP-0060:

http://www.xmpp.org/extensions/xep-0060.html#example-133

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070330/ac509bcb/smime-0001.bin