[Standards] pubsub/pep auto-creation

Pedro Melo melo at simplicidade.org
Fri Mar 23 22:45:51 UTC 2007


Hi,

On Mar 23, 2007, at 5:35 PM, Peter Saint-Andre wrote:

> Rachel Blackman wrote:
>>> I agree. Let's say that I want to start publishing my geolocation  
>>> info. I will explicitly set that up via the client I'm using at  
>>> the time and will set the node config to (say) publish only to my  
>>> Friends roster group. So the PEP service will store that  
>>> preference for all eternity, until I decide to change it (as  
>>> Ralph says, a rare occurrence compared to the volume of  
>>> publishes). If I use another client, that client should respect  
>>> the previous node configuration and not change it willy-nilly, or  
>>> even show it to me at all (assume that I knew what I was doing  
>>> when I set up the node). After all the same individual (me) is  
>>> controlling all the clients that may interact with the PEP  
>>> service so I don't understand why the config would change all the  
>>> time. And storing the preference in iq:private seems really silly  
>>> to me, because the PEP service itself already has a way to store  
>>> the preference -- it's called the node configuration!
>> Great, except...
>>> Configure once, publish from everywhere. Seems pretty simple to  
>>> me. What am I missing?!?!
>> ...you're missing that clients don't always behave as they should.
>
> It seems wrong to design protocols based on the assumption that  
> they will be implemented incorrectly. We don't want our protocols  
> to be brittle, but I think the developers in our community are  
> smart enough to do things right. And if they don't, we file bug  
> reports. :)

Clients will have bugs, some might even think that their way is  
better. Without publish+configure, the other clients can't fight a  
rogue client.

Making your protocol resilient to failure of one of the actors  
involve doesn't seem to me to be a bad design decision, it seems to  
be a good one.

Let me see if I can enumerate the pro and con of all this. I'm biased  
of course, so please complete each of the lists:

  * pro publish+configure:
     1. clients don't depend on other clients "doing the right  
thing" (even if the right thing is objective and not subjective as  
most of the cases will be);
     2. the protocol is simpler on the common case, publishing. 1  
stanza;
     3. it should be an optional feature, so we are not imposing this  
on every publish if we don't need/want to (although personally I  
think we should).

  * con publish+configure:
     1. there is an overhead of traffic on each publish, the common  
case.

Best regards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
Jabber ID: melo at simplicidade.org
Use Jabber!





More information about the Standards mailing list