[PubSub] Suggestions for new node configurations

Nathan Fritz nathanfritz at gmail.com
Tue Apr 21 14:32:06 CDT 2009

On Tue, Apr 21, 2009 at 10:43 AM, Robin Collier <robincollier at hotmail.com>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.)

I would suggest that you use PEP for extending presence, which is
essentially a pubsub node handled by the server in the bareJID's name with
automatic subscriptions based on Service Discovery/Entity Capabilities to
advertise interest.  Instead of having multiple items in a node for each app
(thus needing the cleanup you're talking about), I suggest a node per app.
A separate, non-PEP node could be used to store a log of activity for

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

You're asking things of the spec that are beyond the spec's purpose.
Cleanup and maintenance are not part of the spec.  If a server chose to have
a configuration option for maintenance they could.  If a service provided
said maintenance behind the scenes, great.  I think the real problem is that
you're trying to extend presence and and also maintain a log of activity,
the first of which is better in PEP, and the second of which is better with
traditional pubsub.  If you require complicated maintenance, perhaps a "node
as code" approach is more appropriate, where you behave within the spec for
API, but have background behaviors outside of the spec.


> 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
> >
> > Hash: SHA1
> >
> > 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
> >
> > iEYEARECAAYFAknt9dUACgkQNL8k5A2w/vyKAwCgu+XAM6cf8HFN9rQ8bOK/9w9g
> > zZ8AoNP27ozLwLHxH+0hm/smy28GD6lc
> > =4X5R
> > -----END PGP SIGNATURE-----
> ------------------------------
> Tell the whole story with photos, right from your Messenger window. Learn
> how! <http://go.microsoft.com/?linkid=9650732>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/pubsub/attachments/20090421/548b7224/attachment.htm>

More information about the PubSub mailing list