[Standards] pubsub/pep auto-creation

Ian Paterson 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 
written).

I think we need to consider the likely user interface for a real life 
example.

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 
unnecessarily user-unfriendly.


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.

- Ian




More information about the Standards mailing list