[Standards] pubsub/pep auto-creation

[Rachel Blackman]

> I'm also in the 'publish+configure' camp, and agree to the points
> mentioned earlier about atomicity, burden of the client, ...

Likewise.  I think requiring the client to track what a node's  
existing configuration is violates the 'simple clients, complex  
servers' goal XMPP supposedly aims for.  The server /knows/ the  
configuration; the client doesn't.  If I'm on from a client on my  
Windows box, then go move to my MacBook Pro and a completely  
different client to go down to the coffeeshop, the new client will  
have to query the configuration of every single node it might care  
about.  It makes much more sense to include any non-standard  
configuration in the publish stanza itself.

The alternative is that the client needs to check the configuration  
potentially /every/ time they publish.  Even query once on login  
isn't sufficient; if I'm logged in from two resources, and one  
changes the configuration of a PEP node, the other client may not be  
aware of it.  After all, there doesn't appear to be a 'push' of node  
configuration to all connected resources in PEP, at least that I spot  
on a skim.

So this means for a client to /ensure/ a good publish, it will need  
to a) ensure the node exists, b) create (with configuration) if it  
doesn't, c) check the configuration of the node on every subsequent  
publish, d) change the configuration if necessary, and finally, e)  
actually publish some data.

If our goal is to reduce traffic, we're not really accomplishing it  
here as things stand.

This can be fixed, sure, with a query of every node the first time  
you want to publish to it after a given login (you cannot count on  
the configuration remaining the same across logins if you've logged  
in from more than one client, after all), and a push of node  
configuration to all connected resources any time it changes.  But at  
that point we're getting into designing ways to try and push  
information to the client which, first of all, the client only cares  
about in the event that the information is *incorrect*, and secondly,  
the client will simply overwrite if it /is/ incorrect.  So I'm not  
sure the general convenience of publish+configure is really trumped  
by the minimal increase in traffic from client-to-server for publish 
+configure.

In fact, I'm pretty sure it isn't; I'm fairly sure the general  
convenience factor is the long-term win.

I can go either way on the autocreate; I like the general convenience  
factor of autocreate, but since it is a (theoretically) once-and-only- 
once cost, it's not a huge inconvenience.  But I think publish 
+configure is definitely the direction we need to go.

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/