[standards-jig] JEP-0060 comments

Greg Hewgill greg at hewgill.com
Sun Jan 26 16:40:55 UTC 2003

On Mon, Jan 06, 2003 at 04:08:42PM -0700, Peter Millard wrote:
> Yes. As you pointed out unique + required is too strict for simple
> applications. I would think that if an implementation chooses to NOT
> implement persistent item storage, then id's would never be necessary.

I'm still a bit hung up on this item id design. First of all, section 5.1.2
specifies a publish request with a specific item id, and does not mention the
possibility or behaviour of a publish request without a node id. The ability to
omit the item id is only vaguely mentioned in section 7.2. No other discussion
of the simple case of item-id-less operation is offered.

This new <retract>, which depends on the presence of item ids, doesn't seem
very useful to me either. What exactly is it that the publisher would be
retracting? The published item has (presumably) already been delivered to all
the subscribers. You can't take that away. This would only serve to remove the
published item from the history, and only for a node that supports persistent
items anyway (otherwise the publisher has no way of identifying the item to

Your quote above seems to imply that item ids would be necessary for nodes that
support persistent storage. This almost makes sense, except that in the case
where only item notifications are delivered, the subscribers must have a way to
identify a specific item to get.

Deleting an item from a node is apparently available only to the entity who
published that item. However, section 7.2 indicates that it is possible that an
implementation allows different publishers to "overwrite" an existing item with
an id. How is deleting an item published by a different entity different from
publishing an item with the same id and overwriting whatever was there

The analogy that I keep coming back to is that of an email announcement list
(like news at jabber.org). There are one or two publishers, and a ton of
subscribers. Publishing an item (message) causes it to be immediately delivered
to all the subscribers (ignoring the case of "digest" subscribers). Publishing
a message doesn't require that the publisher choose a new, unique message id. I
think it's essential that the pubsub component allow this kind of operation.

I think something that would really help would be examples that justify the
presence of some of these features. I'll take a stab at this here.

Type 1: Event messages, no history required.

This case is arguably the simplest case of pubsub use. Subscribers only want to
be notified whenever some event happens. The fact that this event happened in
the past is not useful, so no history would be needed. An example might be a
doorbell ring. Subscribers would be notified when somebody rings the doorbell,
and they would have a limited amount of time to respond before the visitor
leaves and the fact that the event happened is no longer relevant.

Type 2: Event messages, history required.

This case would notify subscribers that something happened, and it might be
useful for subscribers to look back in the past to see what happened
previously. For example, a system connected to a secure entry door might send
out notifications whenever an authorized user enters the door (or whenever an
unauthorized user attempts entry). The useful information in these
notifications would be "who" and "when", and these would be stored as part of
the items in the node history.

Type 3: Status messages, no history required.

This case deals with the state of some physical thing. Subscribers want to be
notified of a change in state, but history is not useful. For example,
notification that a router is currently exceeding some bandwidth threshold.
Published items would contain either "yes" or "no", and history is not terribly
informative for this case.

Type 4: Status messages, history required.

This case also deals with the state of some physical thing, but offers more
information. Subscribers want to be notified perhaps of state changes for a
discrete thing, or periodically of some continuous thing. For example, a
discrete thing might be the channel to which a television is currently tuned. A
continuous thing might be the level of coffee in a coffee pot or the CPU
temperature of a computer (or to continue the router example, the 5-minute
average bandwidth use).

Type 5: Sequential messages, history required.

This case deals with sequences of events, where the order and existence of each
item is critical. For example, consider subscribers watching a chess match
where each move is published as an item. Subscribers must be notified of each
item, in the correct sequence, and must be able to retrieve past items in case
they miss any.

Can you provide general categories and specific examples of how you envision
features like unique item ids and item retraction will be used?

Greg Hewgill
JID: ghewgill at slacker.com

More information about the Standards mailing list