On Thu, 11 Nov 1999, Allen Briggs wrote:

> > I'm still unable to retrieve the SAF-TE bits.
> 
> Same here.  "A network error occurred."

Yeah- I have the spec, but I'm not quite comfortable passing it out- they
had some whine about this on the website.

Basically SAF-TE is a slightly different approach than SES in
implementation details but mostly is the same in overall architecture
except it's much simpler. They use READ BUFFER and WRITE BUFFER commands
to set and retrieve enclosure specific status. In addition to having
specific temperature elements with values, they also have 1 summary and 16
bits of overtemp warning (which you synthesize into 17 different
temperature elements if you emulate SAF-TE thru SES).

There were one or two items that had no correspondence, but they didn't
seem very important and I don't remember them off the top of my head.


> > Is it accurate (Matt?)

I'm sorry, I must have lost some mail here..

> > to say that what is being advocated is to make ENVSYS 1.0 return data
> > and accept configuration in an SES-like manner? (i.e., every device must
> > accept SES commands and return results using the data structures described in 
> > ftp://ftp.t10.org/t10/drafts/ses/ses-r08b.pdf)
> 
> That's not what I'm after.  I'm after a generic interface for
> environmental controls that is hopefully generic enough to be useful
> for at least basic control of SES devices (both read and write).

Yes- me too and then some. What I'm hoping for is a simple enough object
abstraction so that the underlying actual transport, be it SES or SAF-TE
or DTMF or i2c, can be both accurately represented and controlled by the
same endpoint management tools that do not have to be aware of the
different underlying mechanism. 

This can turn into the classic case of fine control vs. over-
generalization, but what I see happening is a plethora of h/w
standards with ad hoc software wrappers around them. Bad juju, mon.....


> When I looks at what you were after and thought about what I think I'm
> going to be wanting in the near future, I thought of the little bit of
> work that I did recently with the mixer (porting a gaming library over
> for FlightGear :-).  The complexity seemed similar to me and the mixer
> interface grew on me as I worked with it some...
> 
> > Many environmental sensors have no idea what physical phenomenon is
> > attached to a particular ADC.  This sort of structuring is necessarily
> > provided by userland.
> 
> That would seem like a natural for adc0/adc1/adc2/etc.  If other devices
> _do_ know what they're controlling, then we can plug that information
> in.  I like your notion of being able to configure the names at run-time.

so do I....