SNVT union example in oBIX

["Brian Frank" <bfrank@tridium.com>]

Jeremy promised a Lonworks union example, and I promised a proposal how I would do that in oBIX.  For now let’s assume we do this completely on top of the existing spec (we will discuss ways the spec could be changed below). 

 

In this example, a camera is told to go to a particular position.  It could be a pre-defined position that is denoted by a number (SNVT_pos_ctrl.value.number), or by the coordinates (SNVT_pos_ctrl.value.abspos.xxxx):

 

typedef struct{

   unsigned long receiver_id;

   unsigned long controller_id;

   unsigned short controller_prio;

   cam_func_t function;

   cam_act_t action;

   union{

      unsigned short number;

      struct{

         signed long pan;

         signed long tilt;

         signed long zoom;

      } abspos;

   } value;

} SNVT_pos_ctrl;

 

In oBIX I would probably model this as three contracts;  let’s assume these contracts are standardized within Lonmark using some www.lonmark.org URI with a prefix of “lon”:

 

  <obj href="”lon:PosCtrl”>

     <int name=”receiverId” min=”0” />

     <int name=”controllerId” min=”0” />

     <int name=”controllerPrio” min=”0” />

  </obj>

 

  <obj href="”lon:PredefinedPosCtrl”" is=”lon:PosCtrl”>

     <int name=”number” min=”0” />

  </obj>

 

  <obj href="”lon:CoordinatePosCtrl”" is=”lon:PosCtrl”>

     <int name=”pan”/>

     <int name=”tilt”/>

     <int name=”zoom”/>

  </obj>

 

I didn’t fill in the max, but easy enough to do if important.  Then I might use those contracts for a camera object:

 

  <obj href="”/SomeCamera”>

     <op name=”moveTo” in=”lon:PosCtrl”/>

  </obj>

 

That’s also probably how you would tackle that in an OO language like Java or C# too.

 

Bob brought up another excellent point – if I’m a client how do I know what the possible concrete implementations of lon:PosCtrl I have available to me?  If I was auto-generating a user interface then I could use this to prompt the user for the correct choices.  The simplest solution is to just say “you can’t” – the client and server have to have agreed about what contracts are acceptable as part of some specification.  That actually probably covers a whole lot of practical cases.

 

However, I think it very useful to think about how it could be taken further.  In a strongly typed, define everything up front solution I would probably provide the list of contracts in another property as a list or an enum.  In a looser typed environment, it might be cool to let a server answer questions about contracts like “tell me all the sub-contracts which implement this contract”.  In my experience the latter mechanism is immensely powerful and we use it extensively in Niagara for dynamically binding types together (for example give me all the editors you have on this type, or give me all the device types found which work with this driver).  Although my current thoughts are that it premature to attempt a standardized kernel spec level solution.

 

Brian