[Standards-JIG] pubsub: cache-last-item

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Tue Jan 31 14:36:22 UTC 2006

I am in favor of 2 being a MUST. Every PubSub system out there is behaving
that way, and it just right to indicate the current state to a new
subscriber rather than waiting for the next state change publication. 

And IMHO, if the word caching is meant as 'keep available for further use'
and point number 2 becomes a MUST, then point number 1 will automatically
become a MUST as well.


-----Original Message-----
Message: 1
Date: Mon, 30 Jan 2006 15:28:28 -0700
From: Peter Saint-Andre <stpeter at jabber.org>
Subject: [Standards-JIG] pubsub: cache-last-item
To: standards-jig at jabber.org
Message-ID: <43DE930C.3070506 at jabber.org>
Content-Type: text/plain; charset="iso-8859-1"

Hash: SHA1

I want to make sure that the proposed "cache-last-item" functionality is
clearly understood before we move forward with revisions to JEP-0060. My
understanding from the list discussion last fall was this:

1. Even if a node or service is not configured to support item
persistence, it SHOULD cache the last item published to each node.

   Question: should this be MUST?

2. When a subscription is accepted/approved, the service SHOULD send the
last published item to the new subscriber.

   Question: should this be MUST?

Is this consistent with our discussion last fall?

Note that this obviates the need for a "subscribe-and-get-last-item"


More information about the Standards mailing list