[Standards] pubsub/pep auto-creation

Kevin Smith kevin at kismith.co.uk
Tue Mar 20 09:51:49 UTC 2007

I'm sorry I couldn't be at this council meeting, something  
unavoidable (and considerably more important) came up - I would have  
preferred if it hadn't. This mail is now a bit of a mess, as I try to  
address the points in the mail, and the points in the meeting at once.

On 19 Mar 2007, at 22:47, Peter Saint-Andre wrote:
> XEP-0163 says that if a node does not exist, the PEP service should  
> auto-create the node on first publish:

As well it should!

> http://www.jabber.org/muc-logs/council@conference.jabber.org/ 
> 2007-03-14.html#13:20:19
"<ralphm> I say the normal way is always only trying publish. If it  
fails, because of node-not-found, then try creating it"

This is against all sense of automation (which is why we use  
computers, surely). When you're sending a publish to the service/ 
server, you're saying "I want this node X to hold this value Y" - the  
desired outcome from the service is clear - after the stanza has been  
processed, the node X should hold the value Y. Having the server say  
"only if you tell me to create it first" and the client saying "ok"  
is entirely redundant.

I'm reminded of a story a schoolteacher once told about a pupil  
coding some coursework for a fitness system. He said that the pupil  
coded it such that you had to first input the distance you ran, then  
the time it took you, and then the program told you to go away, get a  
calculator, divide one by the other and input your average speed. The  
program in question knew what had to be done (divide one by the other  
- it even told the user what to do) but it moved this step away from  
the service unnecessarily.

> 1. Remove auto-create on publish. If the client publishes and the  
> node doesn't exist, it needs to create the node (once). This is  
> cleaner.

This is very much not clean, for the reason I noted above. It could  
be made less clean, by the server sending a chat message to the  
client asking the user to open up their client's xml console and  
pasting in the provided stanza, sure, but we're only one level of  
automation away from that - it's unnecessary, the server knows what  
needs to be done.

> 2. Add publish-and-configure.

Is this a bad thing? Semantically this is equivalent to the client  
telling the server "After this stanza has been processed, I'd like  
node X to contain the value Y, with configuration Z" which makes  
quite a lot of sense.

> This may mean that clients will always do publish-and-configure,  
> which is messy but easier for clients.

  In fact, if the concern is that, although saving number of stanzas  
sent (every session), the stanzas will be larger, it's perfectly  
possible for a client to do publish+configure the first time it  
accesses a node, and to only do publish thereafter (and this scores  
on both approaches: the number of stanzas is low and the stanza size  
is low).

> For a while, Ian Paterson had me convinced that publish-and- 
> configure is a fine idea.

He was right :)

> Furthermore, the client will need to keep a record of the desired  
> node configuration for each payload type or NodeID,

There's no getting around this (well, there is, with ugly registries  
of defaults for different nodes, but we really don't want to go  
there) - when a client is publishing and wants a non-default  
configuration, it needs to know what that configuration is, whether  
it's create+configure or publish+configure.

> My tentative conclusion is that auto-create combined with  
> simultaneous publish-and-configure may appear simpler for clients,  
> but is actually more confusing and complex than straight publish  
> combined with node creation if you receive a node-does-not-exist  
> error.

Well, this will come as a complete shock, I'm sure, but I'm in the  
other camp ;)
This feels like the mother who wants the child to say please, but  
without the advantage of teaching good manners:

<child> Can I have a sweet?
<mother> Say please first.
<child> please
<mother> Ok, what do you want?
<child> Can I have a sweet?
<mother> sure!

compare with:
<client> Set this node for me.
<server> Not until you tell me to make it.
<client> Make it please.
<server> Ok, what do you want?
<client> Set this node for me.
<server> sure!

More stuff from the MUC:

"<stpeter> in general I distrust "implicit""
Right, but the implicit step is actually if autocreate doesn't happen.

* With autocreate, the client sends "Node X, value Y" and afterwards  
Node X has Value Y. Nothing implicit in the outcome, the server does  
what it's told.
* Without autocreate, the client says "Node X, value Y" and maybe  
Node X now has Value Y. What the client's message turns out to mean  
is "Node X, value Y, but only if Node X already exists" where the  
'but only' is implicit.

"<ian> also this will make it easier for us to make PEP a slide in  
replacement for iq:private "

Also true, and (although I shuddered a bit when I heard PEP for  
iq:private (I didn't mean it to do this!)) replacing iq:private with  
PEP is a jolly good idea.

" <stpeter> there are pros and cons :)
<stpeter> as always
<stpeter> so we need to weigh those
<stpeter> consider risks and rewards"

And here's the issue I have at the moment, I see no cons to automagic  
node creation (since the clients don't need to reconfigure every time  
they publish (see above) - I grant that forcing that would be a  
little verbose) and I see a whole range of pros.

"<ralphm> I think we need to design good protocols why we can"

"and not necessarily bend over for lazy devs"
When there is a protocol enhancement which makes implementation  
simpler, I think it's our job to use it. Simplicity is an aim of, and  
unnecessary complexity the antithesis of, a good protocol.

"<stpeter> I'm glad that we can have a frank discussion about all  
this :)"
I'll be Frank if you'll be Lauren.

And lastly, before I end this epic...

"<ian> that magic didn't get put in there by accident"


Kevin Smith
Psi XMPP Client Project Leader (http://psi-im.org)

More information about the Standards mailing list