Loading ...
Sorry, an error occurred while loading the content.

259Channel object and WriteGroup

Expand Messages
  • David Fisher
    Mar 1, 2011
    • 0 Attachment

      LA-WG

       

      This morning's conference we discussed the Channel object and WriteGroup service in

      the context of using them to write to the LO object Lighting_Command property.

      I was tasked with researching this.

       

      In reviewing Add-135-2008aa-PPR1-6 it is clear that the Channel object, as currently

      crafted, only supports writing to Primitive datatyped properties. So the constructed

      datatype needed for Lighting_Command, as currently written, cannot be used

      with the proposed Channel object.

       

      Similarly, the WriteGroup service, as currently written, now only supports

      primitive data for the written value(s).

       

      I think on reflection that this is a problem that we must reconsider. There are various

      ways to handle this. Although the Channel object and WriteGroup could be

      reformulated to allow broader datatypes, it's my belief that this will meet

      stiff resistance as there is already a consensus that lead to the current proposals.

       

      We could, of course, not attempt to make any change to the LO object which

      would mean that Channel object and WriteGroup could only be used to

      write to Present_Value. I think this would be a major compromise in the

      ability of this suite of objects and service to meet the needs and use cases

      for Lighting however.

       

      So I believe that a better direction would be to rethink the concept of the

      Lighting_Command to allow it to be served by Channel object and WriteGroup,

      as already proposed in 135-2008aa. To that end, the Charstring and Octetstring

      datatypes come to mind. We could define a fixed position datatype (like Date and Time)

      as an Octetstring and use it for Lighting_Command instead of the new

      constructed datatype currently proposed. However, this is awkward and inflexible.

      The Charstring seems more naturally suited to this task.

       

      I know this is going to be controversial, but it may be the best compromise.

      I raise these issues because now that we are revising the LO object for its

      public review, it would be better to introduce this idea now instead of later.

      I'd like to add this to our crowded agenda for the 15th telecon.

       

      David Fisher

      PolarSoft® Inc.

      914 South Aiken Ave

      Pittsburgh PA 15232-2212

      dfisher@...

      www.polarsoft.biz

      412-683-2018

      412-683-5228 fax

       

      _,_._,___

    • Show all 5 messages in this topic