[PubSub] Suggestions for new node configurations

Peter Saint-Andre stpeter at stpeter.im
Wed Apr 22 09:54:53 CDT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
>> type).

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).

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknvL70ACgkQNL8k5A2w/vw71QCgqfPazeajqqSzZzrlXatNf2G0
SdkAoKsedl6gHo0xyC+7tiJWQI7P43v5
=fRIK
-----END PGP SIGNATURE-----



More information about the PubSub mailing list