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

Bob Wyman bob at wyman.us
Wed Jun 23 16:37:42 UTC 2004


These comments are partial and probably flawed. There hasn't been much time
to review the new draft. But, I wanted to get these in before the meeting
later today at 17:00UTC.

 

*	Support for specifying options at the time of subscription does not
seem to be mentioned. Is this an oversight, or, was my request for such
support denied for some specific reason? In content-based systems one is
*always* going to need to specify options and those options should be
considered in the process of approving subscriptions. The subscription
process would be exceptionally cumbersome if one had to first subscribe,
potentially wait for approval, and then specify options. 
*	Support should be provided for allowing the approval/denial of
options specified on subscriptions. In content-based systems, the options
such as the query or lease-duration can be very important elements in making
an approval decision.
*	If a subscriber has modified options, yet the options have not yet
been approved, what is the state of the subscription? (Is it pending?). I
think it might make sense to have two flavors of pending. One says that the
subscription is pending (i.e. "pending") and the other says that an options
request is pending while the subscription has previously been approved and
is running given the current options (this would be "options-pending"). 
*	Example 18: The <headers> SHIM stuff should be a child of <item> not
<message>. If <headers> must be at the <message> level, then it becomes
impossible to send multiple items to the same JID but for different
subscriptions. I would like to be able to send three items in a single
message but have each item tagged as being destined for a different set of
subscriptions. If this can't be done, then let's just get rid of the whole
<items><item> business and just let the published data be a child of
<event>.
*	Example 24: Given that I'm supposed to be able to send multiple
items in a single message, can I send multiple <item>s and multiple
<retract>s in the same <items> list? Or, do I have to send <retract>s in a
different message than <item>s?
*	Example 81: "Subscribers are notified of node removal". It seems
that we should also be telling people that their subscriptions have been
cancelled. We need support for that and the discussion of node removal
should say that people should be notified of cancellation of subscriptions
to a node when the node is removed. (Not everyone will implement a node->sub
index.)
*	10 Collections: Paragraph 2, There seem to be some missing words in
the sentence: "If the subscription type specified on a subscription to a
collection node [????], the subscriber is notified whenever an item is
published to any node contained by the collection." 
*	10 Collections: If you can get messages from any node in a
collection to which you are subscribed, then there should be some discussion
of "type" issues in this context. The problem is that different nodes will
have different pubsub#type schemas. This means that you must be prepared to
receive messages of each type that appears in the collection. Also, it is
exceptionally unlikely that a content-based system will be able to support
subscription filters or queries that reach across many types without
introducing the potentially complex concept of sub-types, base-types, etc.
(i.e. your subscription could only specify elements which were in the
base-type of all types that occurred in the collection.) While this
collection business might be useful in Topic-based systems as written, it
will need additional work to make it useful for content-based systems. In
any case, it needs more words.

 

bob wyman

 




More information about the Standards mailing list