[Standards] pubsub/pep auto-creation
rcb at ceruleanstudios.com
Tue Mar 20 17:15:47 UTC 2007
> 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
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/
More information about the Standards