RE: [obix-xml] Groups - Notes_20040623.pdf uploaded

Title: Message

Aaron,

I know it's premature to go into a detailed discussion about how to fix the 
problems I noticed with the current spec for the DiscoveryNode, but I wanted to 
at least list them so that we can discuss them later.

 
In bullet # 7 in the Discussion section of the 20040623 meeting 
notes (on the impact of large numbers of services): we should also mention the 
unnecessarily large effort placed on oBIX servers.  That is, when there are 
a large number of services, an oBIX Server would be required to: (a) figure out 
all the services that support a given node, and (b) generate and transmit a 
large discovery response.  Almost all of that effort would, in general, be 
wasted because I suspect that most oBIX clients would be interested in only a 
relative handful of the services listed (probably just one).

So, the 
current DiscoveryNode schema (with embedded service ids) presents several 
problems:

  
It forces an oBIX server to do a lot of unnecessary work in order to 
  respond to a discovery request.

  
It forces an oBIX client to do a lot of unnecessary work in order to 
  handle a discovery response.

  
It forces the transmission of unnecessarily large pieces of 
  data, hogging up bandwidth for clients and especially servers.

  
It presents an inherent versioning problem as more services are added 
  -- especially as proprietary services are added, since perhaps only 
  some oBIX servers should even know about them.

  
It presents ambiguous results.  If a service id field (say, "fooId") 
  is missing from a response DiscoveryNode, it might be caused by any of the 
  following:

  
    
The "foo" service does not support this node.  This is the 
    currently documented meaning.

    
The oBIX server was not programmed/configured to support the "foo" 
    service.

    
The "fooId" field is not in the version of the DiscoveryNode schema 
    currently used by the oBIX server (the "foo" service might actually be 
    available, and might actually support this node).

    
An error occurred that prevented the creation of the "fooId" 
    field.  (If the base Response schema were to be defined to require 
    error information covering this case, then that could remove this 
    ambiguity, but at the cost of more complexity.)

The solution of adding a "filter" to the discovery request (e.g., 
a list of the desired services) is good, but only solves problems 1 to 3.

 

Sam

 

-----Original Message-----
From:  [mailto:]
Sent: 
Thursday, June 24, 2004 8:32 AM
To: 
Subject: 
[obix-xml] Groups - Notes_20040623.pdf uploaded

The document 
Notes_20040623.pdf has been submitted by Aaron Hansen () to 
the oBIX XML Standards SC document repository.

Document 
Description:

Download Document: 
http://www.oasis-open.org/apps/org/workgroup/obix-xml/download.php/7437/Notes_20040623.pdf

View 
Document Details: http://www.oasis-open.org/apps/org/workgroup/obix-xml/document.php?document_id=7437

PLEASE 
NOTE:  If the above links do not work for you, your email application may 
be breaking the link into two pieces.  You may be able to copy and paste 
the entire link address into the address field of your web 
browser.