[Standards] pubsub/pep auto-creation
ian.paterson at clientside.co.uk
Fri Mar 23 15:48:44 UTC 2007
Ralph Meijer wrote:
> On Thu, 2007-03-22 at 23:09 +0000, Pedro Melo wrote:
>> I think what me and others are saying is that we don't trust the node
>> to keep its configuration, and prefer to send the configuration
>> parameters on each publish to make sure they are correct.
>> if I only connect with my usual client, that would be wasteful, I
>> agree. But if we start using multiple clients/resources (PC, Mobile
>> phone, agents) then trusting the node configuration to stick is tricky.
> Like Peter, I don't understand this. Why wouldn't the configuration
> stick? Are we now assuming programming errors or deployment issues to
> guide our protocol design?
No, the user may simply be logged in with another client that may change
the configuration. Such changes may be legitimate since when specifying
a well-known node, a XEP may make the value of a configuartion field
optional, or it may not specify a value for the field at all (perhaps
because that configuration field wasn't even defined when the XEP was
I think we need to consider the likely user interface for a real life
The example being used on this list has been of a node that may be
legitimately configured to be "public" or "private". For example,
imagine a "Home Address" node. The client will probably present the user
interface for the node in a dialog box with the address fields, and with
a checkbox "Publish my Home Address publicly".
That user interface will force the client to either:
1. configure the node every time it publishes, or
2. request the configuration of the node before every publish (the user
may be logged in with another client) and then, at least some of the
time, reconfigure the node before publishing.
As has already been pointed out, the second option is vulnerable to race
conditions (when two clients are in use). IMHO, that fact alone makes
the idea a non-starter. In this example, the best solution is to
configure the node upon every publish.
An alternative user interface would separate the configuration from the
publishing (e.g. by hiding the public/private option somewhere amoungst
the user preferences), and present a publish dialog with only the
address fields. However, IMHO, that would be significantly and
The above example was for the "Home Address" node. I expect you can
imagine other nodes where a different user interface might be
appropriate (e.g. geolocation). But as someone said yesterday, clients
need the flexibility to do things in different ways (often as a result
of different user interface designs). Nothing about the
publish+configure proposal forces clients to use it at all. IMHO clients
will typically use it for some nodes and not for others.
More information about the Standards