Hi,
I've finished the implementation of my "Metrology Service" (apologies for not posting this as a followup to that original thread but I have no pointers to it here).
In essence, the service exports three verbs:
RESET [] SET TO GET
where:
::= ACCURACY | ERROR | RESOLUTION | PRECISION | RATE | h MINIMUM | MAXIMUM
These should be intuitively obvious (though the names ACCURACY and ERROR need clarification: ACCURACY = % of reading; ERROR = absolute error. And, without argument, RESET obviously resets all s). This level of granularity allows single-valued return parameters instead of requiring support for tuples, etc.
The code is amusingly tiny and, like most of my work, table-driven. I suspect the design of the tables will change with experience (I am now "applying" the service to a variety of devices so I'll soon learn what "unfortunate" assumptions I may have made!)
So far, the most amusing aspect has been the times when the service returns "FAIL" for a request -- after much head scratching, I invariably discover I have requested a configuration that the device in question simply can't
*provide* (and the service is correctly informing me of that!)I'll publish the API, specification and sources with all this other stuff when I get a chance... Of course, only the conceptual design will be portable as my operating environment provides mechanisms that aren't often available elsewhere :-/ (so those parts of the implementation will need to be "fitted" to other environments)
I also have an analysis of the pros/cons of lex/yacc/adhoc parsing that fell out of this design effort. But, writing that up formally is presently a very low priority task. :-(
Apologies if I don't reply as I am traveling (little time to establish good connectivity, read *or* compose posts :> ).
--don