> Date: Mon, 14 Sep 2009 15:41:29 -0600
> From: [email protected]
> To: [email protected]
> Subject: Re: [PubSub] Suggestions for new node configurations
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 4/21/09 1:36 PM, Peter Saint-Andre wrote:
> > On 4/21/09 11:43 AM, Robin Collier wrote:
> >
> >> Well, I will be enabling (2) with the application I am building (I
> >> thought that one might be somewhat contentious). Although I think there
> >> will be other use cases where published items will only be relevant
> >> during the time when the user who published them is still present.
> >
> >> In my own case, we are using a pubsub node to notify users of an
> >> application of what other users are doing, if they are interested. The
> >> interest level is typically determined by whether the users are in the
> >> same group. It's basically a near real time state update to relevant
> >> parties. (It would be even better if I could utilize collection nodes
> >> as well, but that part of the spec is too immature at this point.)
> >
> > Purging the node when the node owner (presumably the *only* node owner)
> > goes offline might be appropriate for certain kinds of extended presence
> > applications. I have no deep objections to defining a node configuration
> > option for that feature, I was just wondering about the use cases and
> > whether this kind of thing would need to be enabled on a per-node basis
> > (I think the answer is probably yes, since it depends on the payload type).
>
> I've added a purge_offline node configuration option for this.
>
I must have missed that reply to my original request. What I was referring to
was the ability to purge the publishers items, not the entire contents of the
node. This would be useful when the information being published is only
relevant
while the publisher is online. It effectively extends the concept of presence
to the
items that have been published by having their lifecycle directly tied to the
publisher
that created them.
I think the idea of purging the node when the owner goes offline is going to
cause many other issues.
- Does this turn the node 'off'. After all, there isn't much point in purging
the items
if the node is still available to be published to.
- Do publishers and subscribers get notified of a configuration change that
indicates
the node can no longer get published to?
- What happens when there is more than one owner?
> >> I am somewhat surprised that the 1st item is not already part of the
> >> spec, as I see it as much more desirable than max_items, the only
> >> current option for limiting the volume stored. I would think that for
> >> most multi user applications, determining a hard value for the number of
> >> items you wish to keep would be more difficult than determining at what
> >> time they are no longer relevant.
> >
> > This is typically a service-wide configuration option, not a per-node
> > configuration option (e.g., the admin of your pubsub service decrees
> > that nodes shall not contain items more than 30 days old as a form of
> > garbage collection). Why exactly does this need to be a per-node option?
>
> It's still not clear to me if we need a per-node option for this, but I
> suppose it's fine since we already have max_items.
>
> Thoughts?
>
> /psa
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkquuIkACgkQNL8k5A2w/vzbDwCgqwlOLB6L3yPDcV3/0En9bnm1
> 684AoLkW3lfk1P6KPdiTBLoBMNRrIx0n
> =MdyS
> -----END PGP SIGNATURE-----
_________________________________________________________________
Create a cool, new character for your Windows Live™ Messenger.
http://go.microsoft.com/?linkid=9656621
