[PubSub] Suggestions for new node configurations

Robin Collier robincollier at hotmail.com
Wed Apr 22 10:23:28 CDT 2009

> Date: Wed, 22 Apr 2009 08:54:53 -0600
> From: stpeter at stpeter.im
> To: pubsub at xmpp.org
> Subject: Re: [PubSub] Suggestions for new node configurations
> 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?

Fairly different from what I was suggesting.  If you are just going to purge the node, should it just be deleted instead?  I would assume there would be no more items published after this purge anyway.  

For my case, it was only deleting items posted by the user that goes offline.  All other items would still be considered relevant.  Not sure how much overlap this have with PEP, but I believe the requirements are somewhat different (although I admit I am not that familiar with PEP)

> >>> 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/
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> iEYEARECAAYFAknvL70ACgkQNL8k5A2w/vw71QCgqfPazeajqqSzZzrlXatNf2G0
> SdkAoKsedl6gHo0xyC+7tiJWQI7P43v5
> =fRIK

Internet Explorer 8 helps keep your personal info safe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/pubsub/attachments/20090422/ba821b40/attachment.htm>

More information about the PubSub mailing list