Hi,
OK, I finished the design of a metrology service. The goal, here, is to allow clients to dynamically (re)configure the server to provide its data in a way that best fits the client's (application's) needs -- WITHOUT any a priori knowledge of the capabilities of the device being served *or* the requirements imposed by other concurrent clients (!)
The service is connection oriented -- stateful. So, the characteristics required by each client are bound to that connection.
Essentially, I allow the client to query the current range of values for any of several parameters (one at a time). Within that range, the client can *specify* a value for that parameter at any time. This, in turn, may affect the range of values available for *other* (as yet, unconstrained) parameters.
The server is free to give the client *better* performance than specified but never worse. The client can examine the current value of any particular parameter (even though the client should, theoretically, *know* what it requested of the server for that parameter!).
Obviously, the ranges for each parameter vary with the device being served. And, the relationships between these parameters will likewise have device-specific interactions. My framework handles these with up-calls to device specific methods in the server.
I've had a hard time settling on the right set of parameters to support. Keep in mind, the framework has to support a variety of devices so tailoring the parameters to a particular device or device class is not acceptable. (the API also needs to be consistent!)
I allow the "high" limit on a measurement to be specified. The server is free to support *higher* than specified. Likewise, the "low" limit -- the server can support *lower*.
I allow accuracy to be specified as percent of value as well as "absolute" accuracy. Of course, the server can provide more accuracy than requested.
The client can request a desired resolution (fineness of measurement) as well as update interval. The server can provide finer measurements and more frequent, respectively.
So, to put it together, a (fictitious) client-server dialog for a temperature sensor might be:
C: get low S: -100 (e.g., degrees C)
C: get high S: 200
C: get error S: 0.25 (degrees C)
C: get tolerance S: 0.5 (%)
C: get resolution S: 0.1 (degrees C)
C: get rate S: 100 (Hz)
Note that this defines the most permissible operating envelope for the service -- the device might not be capable of operating within these UNCONSTRAINED parameters (e.g., the resolution might increase -- get worse -- if operated near the high end of the range).
The client then refines the actual operating conditions:
C: set low 50 S: 0
In this case, the server has decided that it can configure itself to support a low limit of 0 with no consequences beyond those associated with the requested limit of "50" (i.e., the server is free to provide *better* than requested)
C: get high S: 200
[The high limit capability was not affected by the choice of low limit]C: set high 100 S: 100
C: get tolerance S: 1 (%)
By constraining the operating range, the server refines the best tolerance available FOR THAT RANGE.
C: set tolerance 2 S: 1%
The server feels it can still offer a better tolerance than requested.
C: set rate 5 S: 50
The server can offer faster updates than requested.
C: set resolution 0.2 S: 0.1
C: get rate S: 10
Note that the rate has been reduced -- a consequence of the resolution required.
(etc.)
When all parameters have been specified, the client can query the server for the current operating conditions/configuration. Note that this will be AT LEAST as good as requested but probably
*not* as good as initially advertised (by the server).It is important to note that the server is only contractually obligated to provide the level of service *requested* by the client -- *not* the configuration advertised at the end of the configuration dialog! I.e., if another client connects to the server subsequently, the server might tighten the operating configuration *beyond* this advertisement -- as long as the requested configuration is still supported.
If, for example, the client *wants* to lock in this advertised configuration, then it should explicitly update each parameter with the advertised values AS IF these were its *desired* operating point.
What else am I missing? I haven't made up my mind on "precision" as I think it is too hard to find specified on most devices.
And, I don't know how to address server-side filtering. I think it may be too device-specific to reside on the server (?) -- unless I allow a function to be pushed? (creating such functions would be annoying as they would need upcalls from the server's configuration mechanism to adapt to changes in the *actual* configuration of the service -- e.g., if update rates change...)
Thx,
--don