[Standards] pubsub/pep auto-creation

[Peter Saint-Andre]

XEP-0163 says that if a node does not exist, the PEP service should 
auto-create the node on first publish:

http://www.xmpp.org/extensions/xep-0163.html#owner-create

Naturally this raises the question: "What about doing simultaneous 
publish-and-configure?" For instance this is assumed in XEP-0189:

http://www.xmpp.org/extensions/xep-0189.html#usecases-pub

Last week the XMPP Council discussed the issue at length in its meeting:

http://www.jabber.org/muc-logs/council@conference.jabber.org/2007-03-14.html#13:20:19

In essence there are two views:

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.

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

For a while, Ian Paterson had me convinced that publish-and-configure is 
a fine idea. Now Ralph Meijer's arguments have made me think I'm not so 
sure. :)

Consider the possible protocol flows (pseudo-XMPP follows).

1. NO AUTO-CREATE

The client tries to publish to the node (in PEP this would be something 
like user mood or some other well-known node). In the vast majority of 
cases, the node already exists because it's well-known and everyone is 
using PEP (right? ;-). So a straight publish will work:

C: <iq type='set'>
      <pubsub>
        <publish/>
      </pubsub>
    </iq>

S: <iq type='result'>
      <pubsub>
        <publish/>
      </pubsub>
    </iq>

In a few cases, the node does not exist so the client receives an error 
and needs to create the node before publishing, like so:

C: <iq type='set'>
      <pubsub>
        <publish/>
      </pubsub>
    </iq>

S: <iq type='error'>
      <pubsub>
        <publish/>
      </pubsub>
    </iq>

C: <iq type='set'>
      <pubsub>
        <create/>
        <configure/>
      </pubsub>
    </iq>

S: <iq type='result'>
      <pubsub>
        <create/>
        <configure/>
      </pubsub>
    </iq>

C: <iq type='set'>
      <pubsub>
        <publish/>
      </pubsub>
    </iq>

S: <iq type='result'>
      <pubsub>
        <publish/>
      </pubsub>
    </iq>

But the client would have to do that only once and would know when the 
node-creation flow is needed (error on publish).


2. PUBLISH-AND-CONFIGURE

Wow, this is easy, right? The client never has to go through that 
bothersome error flow, because it can always do a straight publish in 
full confidence that the node will be auto-created for it by the server:

C: <iq type='set'>
      <pubsub>
        <publish/>
      </pubsub>
    </iq>

S: <iq type='result'>
      <pubsub>
        <publish/>
      </pubsub>
    </iq>

But is it really that easy?

Yes, if the client wants the default node configuration. (The client 
still needs to discover the default config from the server before it 
publishes any items, in case it doesn't like the default config).

No, if the client wants a non-default node configuration. Here the 
client needs to include the configure in the publish it sends.

C: <iq type='set'>
      <pubsub>
        <publish/>
        <configure/>
      </pubsub>
    </iq>

S: <iq type='result'>
      <pubsub>
        <publish/>
        <configure/>
      </pubsub>
    </iq>

And the client will need to do that every time, because it can never be 
sure if the node will be auto-created (unless it explicitly asks the 
server if the node exists before doing a publish, which kind of defeats 
the purpose). Furthermore, the client will need to keep a record of the 
desired node configuration for each payload type or NodeID, since 
otherwise it might overwrite the desired node configuration each time it 
publishes (unless it explicitly asks the server for the node config 
before publishing, which again defeats the purpose).


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. But I'd like to 
hear from client and server developers about their thoughts before I 
reach any firm conclusions. And naturally the rest of the Council may 
have their own opinions, too. :)

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- 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/20070319/0e2a415c/smime.bin