[Standards] pubsub/pep auto-creation

Peter Saint-Andre stpeter at jabber.org
Thu Mar 22 06:34:58 UTC 2007

Ralph Meijer wrote:

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

Especially in PEP it is a one-time event, because in general these nodes 
are going to be well-known via various XEPs. Or are you saying that in 
PEP the server should handle those well-known nodes in a different way 
than a generic pubsub service would handle non-well-known nodes?

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

That's important. Really this is just handling of an error flow by the 
client, it seems to me. No need to bubble that up 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.

How about PEP over PEP as the April 1 spec? ;-)

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

I remain concerned about the potential confusion of always doing 
publish+configure. In part because the client doesn't necessarily know 
what the default configuration is at a service and if the desired 
configuration is for the node and whether the two are different, so in 
practice it seems to me that clients are just always going to do 
publish+configure. And that seems a bit excessive to me.


Peter Saint-Andre
XMPP Standards Foundation

-------------- 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/20070322/2104d7d6/attachment.bin>

More information about the Standards mailing list