[PubSub] Suggestions for new node configurations
stpeter at stpeter.im
Wed Apr 22 09:54:53 CDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 4/22/09 8:01 AM, Robin Collier wrote:
>> Date: Tue, 21 Apr 2009 13:36:10 -0600
>> From: stpeter at stpeter.im
>> To: pubsub at xmpp.org
>> Subject: Re: [PubSub] Suggestions for new node configurations
>>> 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
Do you have further thoughts about this one?
>>> 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?
> I guess I thought of it as simply another way of specifying message
> retention. No different than the max_items case, just a different
> criteria. Since the node itself determines the context of the items
> stored, it makes sense that it is the level at which you would determine
> the validity desired quantity of that information.
> In either case, I won't be using it anyway. I just thought it made
> sense as an enhancement.
I see your point -- it's kind of like the showing only items from the
last 30 days (or whatever) on a blog homepage. But that's a bit
different (more like "number of live items" rather than expiration based
on date -- both might be handy, I suppose).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the PubSub