[Standards] pubsub/pep auto-creation
rcb at ceruleanstudios.com
Fri Mar 23 17:10:36 UTC 2007
> 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!
> 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.
Sometimes because people don't understand the specification (witness
how many people got XEP-0115 wrong initially, based on recent
discussion!), sometimes because they decide 'well, I won't expose
that particular bit of information as a config, it'll just be all
public' to save time or whatever.
If every client can be trusted to 'play nice,' then you're right and
things are just fine as they are in the PEP spec.
It has been demonstrated amply in the past, however, that not every
client will play nice. And so people will write workarounds.
So, I think the part you're missing is that those of us arguing for
publish+configure are sort of looking ahead at, 'well, given that I
don't have any guarantee that Client Z is not going to be re-marking
the nodes all public every time it logs in, how can I still ensure
the proper behavior?' Because if someone logs in with Client Z to
try it out and it changes the node configuration, and then logs in
with your client instead and discovers that say, geoloc is now going
out publicly... what will happen? In my experience, it will be YOUR
client that gets the bug logged against it, NOT Client Z.
So this is basically a 'if things go wrong, how do we fix it
easily?' And, of course, the only way to know that things HAVE gone
wrong is to check the configuration when publishing to check it
against the client-known preferences.
Sure, the ideal is 'everyone just gets it right,' but how often does
THAT happen? ;)
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/
More information about the Standards