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

Fletcher, Boyd C. J9C534 Boyd.Fletcher at je.jfcom.mil
Mon Jun 28 19:24:07 UTC 2004


 

> -----Original Message-----
> From: Bob Wyman [mailto:bob at wyman.us] 
> Sent: Friday, June 25, 2004 11:27 PM
> To: Fletcher, Boyd C. J9C534; 'Jabber protocol discussion list'
> Subject: RE: [Standards-JIG] JEP-0060: Comments on latest draft.
> 
> 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.

this the ambiguity. The draft doesn't describe what happens, yet the draft clearly support sub-nodes. so.....


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

perhaps that will solve our problems. So the sub-node stuff should be removed from the draft?


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

I could see the append, but overwrite=false just drops the message and sends an error.

But their still needs to be a way to know **exactly** how the server will behave at all times. Anything else, results in interoperable/incompatible systems.


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

I agree its not perfect I was using it was stepping off point, but your questions only go to renforce what I've been saying all along, the current specification is too ambiguous (i.e "capable of being understood in two or more possible senses or ways" - merriam-webster)

I'm am concerned about your analogy, if we design a specfication to worry about even the smallest devices (and thus make everything optional) then we will not have a robust and useful protocol for the other 95% of the world. To use an analogy, when X11 was developed in the 1980s it was well understood that most of the machines of time could not effectively run the software. But the designers were more concerned about the future, they didn't want to hamper the design of the X11 protocols because current technology was too limited.



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

but most people seem to be reluctant to make any changes to the specification so at least in my opinion its useless as currently written. 

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


some examples of the things we are trying to do and the problems we are discovering:


1) Create a whiteboard for XMPP using PubSub. 

    a) The specification prohibits a publisher from deleting a node or item a node that he doesn't own. see table 3. Deleting items in a whiteboard is a critical function.
    b) updating is not adequately defined (see all the other emails)
    c) notification behavior of sub-node (including its items) is not defined. this might be resolved with collections.

2) Enhance MUC to support multi-media enabled rooms (i.e. whiteboard, audio, application casting, etc...). We are attempting to implement a token passing method (robost "push-to-talk" or raise-hand )for Jabber.

   - In the existing JEP-0060 there is a concept of private node to which subscriptions are restricted by means of a white list. But the relying XMPP protocol as to how this feature of private node is implemented is not discussed in the existing JEP.
   - In a node hierarchy are we supposed to subscribe to the root node before subscribing to the sub-node?  
   








More information about the Standards mailing list