[PubSub] Suggestions for new node configurations

Robin Collier robincollier at hotmail.com
Wed Apr 22 09:01:00 CDT 2009

> 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
> Hash: SHA1
> On 4/21/09 11:43 AM, Robin Collier wrote:
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting so bad?
> A: Top-posting.
> Q: What is the most annoying behavior on email discussion lists?
> :)
My apologies, as I hide my head in shame.

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

> Peter
> > Date: Tue, 21 Apr 2009 10:35:33 -0600
> >> From: stpeter at stpeter.im
> >> To: pubsub at xmpp.org
> >> Subject: Re: [PubSub] Suggestions for new node configurations
> >>
> > On 4/21/09 10:06 AM, Robin Collier wrote:
> >> 1) Aging off of messages - When node is persistent, having a max age so
> >> that all old messages are automatically deleted.
> >> 2) Deletion based on presence - When node is persistent, all items
> >> posted by a user are automatically deleted when that user signs off.
> > 
> > It's not clear to me if we need node configuration options for these
> > features or whether they are things that a given app will build on top
> > of pubsub.
> > 
> > Peter
> > 
> - --
> Peter Saint-Andre
> https://stpeter.im/
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> hAkAoNh1SqwwnaG3XJRRKo2Eazpe88GE
> =rtwT

Experience all of the new features, and Reconnect with your life.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/pubsub/attachments/20090422/7684b1ef/attachment.htm>

More information about the PubSub mailing list