[Standards-JIG] JEP-0060: Comments on latest draft.
bob at wyman.us
Mon Jun 28 20:35:21 UTC 2004
Boyd Fletcher wrote:
> the draft clearly support sub-nodes.
I think you are reading things into the draft that you may wish were
there but simply aren't. For instance, you seem to think that just because
"sub-nodes" exist that their existence should imply something about the way
that messages are delivered or addressed. Such a connection is neither
necessary nor implied in the specification. There is nothing "ambiguous"
here. What you're talking about simply ISN'T in the spec -- it isn't that it
isn't clearly written -- it is that it isn't written AT ALL!
You are apparently bringing to your reading of the specification
assumptions that come from other contexts... For instance, if you have
experience with TIBCO systems or any of a number of other topic-based
publish and subscribe systems, you probably expect to be able to publish to
a group of sub-nodes by publishing messages to a parent node. That is all
well-specified in those other systems, however; it is NOT supported in
JEP-0060. It is NOT the case that JEP-0060's support for publishing to
sub-nodes via publishing to parent nodes is under-specified or ambiguous. It
IS the case that JEP-0060 simply DOES NOT support this sort of thing. If you
want it, you should be arguing for why it should be provided and why
JEP-0060 doesn't provide you with an adequate mechanism to do what you want.
(See more on this later in this message -- I think JEP-0060 provides what
You say that there are "sub-nodes" in JEP-0060 but there aren't. The
term "sub-node" or "subnode" never appears in the document. The only thing
that even hints of a "sub-node" idea is that you can use Disco to walk
through a hierarchy of nodes. This is shown in 8.1.11. However, the only
thing that you get from what is shown is the ability to DISCOVER nodes. The
fact that you can relate nodes to each other in a hierarchy so that they can
be DISCOVERED does not imply ANYTHING about what happens when you publish to
any one of the nodes that you have discovered. The only time that JEP-0060
provides from subscribing to one node and receiving messages published to
another node is in the discussion of collections. In that case, a message
published to a node which is a member of the collection may get delivered to
a subscriber to the containing collection if the subscription_type is
"items". This should handle most of your needs. Please read section 10 very
carefully. It is the only part of the specification that is relevant to your
"subnode" stuff the discussion of disco in 8.1.11 is not relevant.
In your use-case of drawing on a whiteboard:
You might have a root node called "pens" and if you did a
disco#items on that node you might DISCOVER three pens: "black", "blue", and
"green." These might also be called "pens/black", "pens/blue", and
"pens/green", but the naming of the nodes has no semantic impact on the
system. You could subscribe to any or all of these nodes independently and
severally. However, this could be inconvenient if you wanted to see the
results of multiple pens publishing at the same time.
So, you might create another node called "active-pens" that was a
COLLECTION (as in Section 10) and you could insert the "black" and "blue"
pens into this "active-pens" collection. Then, you could subscribe to the
"active-pens" collection and see what was being drawn by all pens in the
collection (i.e. by both "blue" and "black" but not "green".) This lets you
have the green pen (or any other pens that are not in the active-pens
collection) but also be able to ignore it, or hide it, even if it is
By making the distinction between discovery and subscription, we are
able to increase the flexibility and power of the system beyond the simple
hierarchical model that is implemented by most legacy topic-based systems.
For instance, in most existing legacy topic-based systems, if you had three
pens as items of the "pens" node, then if you wanted to allow pens to draw,
you would have to allow ALL pens to draw or you would have to impose some
sort of filtering to remove some pens from the ones that are watched. This
isn't always what you want.
Does this begin to make more sense?
More information about the Standards