[standards-jig] JEP-0060 comments

Peter Millard me at pgmillard.com
Thu Feb 6 20:58:15 UTC 2003


Greg Hewgill wrote:
> 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.

I'm trying to make it more explicit about NOT having to use item-id's and how
item-ids "play" with persistent items.. I need to think about this to come up
with some business rules. There are some rules about what combinations of config
options MUST have item-ids (like if I'm not delivering payloads, then I SHOULD
have item-ids, and I SHOULD have some kind of persistence there).

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

Right, for persistent items, this is an important concept. Items may be
published, and subscribers do NOT receive the payload in the notification. They
receive just the event. By the time I come online and receive all of my
notifications, 100 items may have been published, but only 50 are available.

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

Yeah, this ties back into my first reply.. If I'm only receiving event
notifications (with no payloads), then it almost IMPLIES that there is some kind
of persistent storage someplace which is storing the items. It's unlikely (but
maybe not impossible) that this is just an in-memory list.

> 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 previously?

One operation (delete) means the item-id is no longer there. The other operation
(over-write) means the item still exists, but the payload has been updated.
These are different concepts. Again, this is a generic protocol that needs to be
able to be applied to all types of node configurations. I believe that we have
to have both of these concepts in order to be "complete".

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

Sure, in this case item-ids would never be used. Notifications would most likely
include the payloads, and persistent storage would not be necessary.

[Examples snipped]

Thanx for the examples... I may be able to incorp these in some way into the
JEP. Hopefully, I'll be able to push another rev out soon.

pgm.




More information about the Standards mailing list