[PubSub] (no subject)

Robin Collier robincollier at hotmail.com
Wed Apr 22 08:50:02 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 look-up.

I don't think that this fits
our use case due to the fact that each client will now require all
other users to be in their roster.  This setup and maintenance will not
likely exist in our particular case, although I admit it probably would
for the typical application.

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.

 
-Fritz

I
fail to see how this is any different then the max_items case.  Both
serve the exact same purpose but simply use different criteria to
determine when to remove older items.  If this is outside of the scope
of the spec, then why supply the ability to limit at all?  By it's
current inclusion (by number) it does in fact make it within the scope
of the spec.

For the record, I am not actually making use of this, but thought it made sense as a feature.

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
> 
> -----BEGIN PGP SIGNED MESSAGE-----

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

> 
_________________________________________________________________
Reinvent how you stay in touch with the new Windows Live Messenger.
http://go.microsoft.com/?linkid=9650731
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/pubsub/attachments/20090422/ebf629ed/attachment-0001.htm>


More information about the PubSub mailing list