[Standards-JIG] JEP-0060: Comments on latest draft.

Bob Wyman bob at wyman.us
Sat Jun 26 03:27:02 UTC 2004


Boyd Fletcher wrote:
>> 	The fact that one node is an item of another node is
>> completely irrelevant in JEP-0060 for any purpose other than 
>> browsing UNLESS the containing node is a Container. In that 
>> case, section 10.1 is relevant.
> humm. yet another ambiguity. Thank was not our interpretation.
	I don't see anything ambiguous about this at all. It is nowhere
stated in the JEP-0060 that "notifications are sent to the subscriber of
the parent node" except in the case of the Collections section that was
added in the last draft. As far as I know, no earlier draft of JEP-0060
defined such a capability.
	Please be aware that, as noted in the minutes of the recent
pubsub chat[1], the Collections documentation needs to be expanded
beyond the first draft that you see online now. For instance, this kind
of multi-topic subscription can cause significant troubles for any
system that enforces "type" constraints on messages published to nodes.
Such limitations are very common in systems that implement content-based
subscriptions. (The reason is that you need to know the "schema" of a
node/topic's messages in order to define a query on the node...) In such
systems, it may be necessary to require that all nodes in a collection
have the same "type" or message schema. We'll then need to think about
how one retrieves the schema for a collection... (i.e. is this metadata
associated with the collection directly or, do we have to inspect the
collection members to discover it?)

> the specification does not (at least to us) adequately explain
> how notification works for sub-nodes or items of sub-nodes.
	As noted before: There is nothing in JEP-0060 about notification
to "sub-nodes." There is, however, a capability to subscribe to
collections. Re-Read Section "10. Collections". The "typo" that pointed
out recently on the list might help clarify things a bit. Otherwise,
wait for the next draft which is promised to expand on the current
words.

> at minimum it must support overwrite, read-only, and append
	These specifications work best when the required features are
limited to those which are critical to ensure minimal function. Defining
an excessive amount of required behavior only ends up forcing
non-conformance in some situations. For instance: Imagine a pubsub
server which is built into an embedded component of a fighter jet or
other weapons system. The embedded server receives messages concerning
temperature, integrity, etc. of system components and allows various
monitoring applications to subscribe to the component status messages.
This is a nice design since it results in a flexible resilient design
that can be reconfigured without impacting the monitored components
themselves. However, as is often the case in such systems, there may be
little read-write memory available. Such an embedded pubsub server
simply cannot implement all three methods that you described. It doesn't
have the memory, for instance, to remember all message id's seen and do
what is required to implement either the "append" method or
"overwrite=false" methods since these rely on memory.
	Before you suggest that this embedded pubsub server is an odd
case, please consider that implementing the two "memory dependent"
methods would also be a burden for a high-volume system like that which
we implement at PubSub.com. We have lots of memory available, however,
even gigabytes might not be sufficient if we have a large number of
high-volume publishers. 
	Also, consider that your specification of the methods is
incomplete. For the "append" and "overwrite=false" cases, how long must
we remember previously seen itemIDs? Are you requiring that itemIDs are
integers or some other scalar, ordered type? Are you imposing a
requirement that itemIDs be monotonically increasing? If so, what is the
behavior of the system when it appears that an itemID has been skipped?
What is the behavior of the system when the counter reaches the limit of
the number of bits allocated to it? Can itemIDs be reused after some
period of time? If so, how long or how do I discover how long? Your
proposal is incomplete. I think you would probably call it
"ambiguous"... (I would argue with that choice of words. :-) )

> What we have now with JEP-060 is a specification in which
> interoperability is impossible.
	No. What we have is a specification that is in the process of
being written... There are very few implementations and thus there is
still much to be learned. You seem to have quite a few requirements for
this capability. Might I suggest that you could help us all if you would
take the time to document your requirements or at least write a bit
about your expected use cases? Or, could you point us to existing DOD
specifications or RFPs for pubsub systems that might allow us to better
understand your needs? 

		bob wyman

[1] http://www.jabber.org/~stpeter/editor/pubsub-notes.html




More information about the Standards mailing list