[Standards] pubsub/pep auto-creation

Remko Tronçon remko at el-tramo.be
Thu Mar 22 07:49:56 UTC 2007

> so in practice it seems to me that clients are just always going to do
> publish+configure.

Indeed, that's the idea.

> And that seems a bit excessive to me.

Why? Rachel pointed out that, if you don't do that, you have to check
the configuration *every* time you publish an event, and possibly
modify the node. It gets even worse: between the check and the
publish, some other resource might have made your node public for a
public item it is publishing, and you're publishing something private
to a public node.

I'm still convinced that specifying the 'how' (public/private)
together with the 'what' (event) is easier to grasp, easier to
implement, and avoids a lot of trouble. I'm also throwing in my
standard excuse of 'stream compression will take care of the extra
traffic' (although actually, it takes a lot more traffic to publish
events 100% correctly if you have to check configuration every time).

Putting the 'how' with the 'what' also makes a few (maybe not yet so
frequent) use cases a lot easier:
- Whenever I play a tune of the backstreet boys, I only want my close
family to know about this. So, whenever a tune of the backstreet boys
comes up, I just say 'publish this item for my friends only'.
- Whenever I leave the building, I want to stop sending my geoloc to
my colleagues. So, depending on the geoloc, I simply say 'publish this
item for non-colleauges'.
I'm sure these sound far fetched, but I'm trying to explain that it's
easier to talk about publicness and privateness of items, than to talk
about the publicness and privateness of the nodes you are publishing
items to, especially if they change dynamically.

But all in all, the convincing argument should be the fact that you
can never assume on a publish that you are publishing an item the way
you want it, unless you check configuration. And even checking doesn't
guarantee you that your item will be published privately if some other
resource is posting public events to it.


More information about the Standards mailing list