[Standards] pubsub/pep auto-creation

Ralph Meijer jabber.org at ralphm.ik.nu
Tue Mar 20 13:40:03 UTC 2007

I'll leave out bits of what Kevin wrote and ignore the haha story
telling. Replies below.

On Tue, 2007-03-20 at 09:51 +0000, Kevin Smith wrote:
> [..]
> > 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.

In general publishing to a node may fail for any number of reasons. One
of them is the node not existing. Sure you would like to always be sure
to have the item published after your action, but you always must check
if it was successful anyway. If the node does not yet exist, you get an
error back with a node-not-found condition.

The point I was trying to make here is the creating a node is a one-time
event and thus a special case that should to be handled differently from
the modus operandus: publishing items.

> [..]
> > 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.
> [..] the server knows what needs to be done.

The tricky bit comes in from the configuration of nodes. If you need a
configuration before the node can be created, the server does not know
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).

Here I say, how does the client know if the node is already there? Have
the first request send a configuration? What if another client
(different machine, for example) already created the node and configured
it? Do you now change the configuration?

My angle is that I find it weird to have the complete desired state sent
in one request, particularly when some of the information is likely to
not have changed.

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

If you are not creating the node, you don't need to keep stuff around. I
like the server to do this for me.

> > 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 ;)
> [..]
> 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.

No, the client sends either "Publish Y to Node X, and create node X if
it doesn't exist", or "Configure Node X, then publish Item Y and create
node X before if it does not exist yet". Both in one exchange. In both
cases the node creation is implicit.

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

No, the client sends: "Publish Y to Node X". In the regular case, the
server replies "OK". Exactly once during the node's lifetime, the server
will respond with "Oops, you tried publishing to node X, but it isn't
there". At this point you can create the node like in 'regular' pubsub.
If the node needs configuring, or you want to configure the node, there
is a process for that.

I like to compare this with exception handling in e.g. Python. You
generally code for the common case, and handle exceptions (hence their
name) separately.

Note that this can all be done transparently to the user.

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

I'm sure it is a matter of opinion. I hope I pointed out the cons as I
see them.

> "<ralphm> I think we need to design good protocols why we can"
> Absolutely.
> "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.

Again, it is in the eye of the beholder. Implementation of some of the
bits just move to the server side. I don't think the protocol, with the
implicits or additional usually redundant information, really is

> [..]



More information about the Standards mailing list