Hi Jerry,
We certainly could use option negotiation (although even that would require
some backwards compatibility.)
We also have had version numbers included in the owserver protocol since the
start -- although there hasn't been a need to progress beyond version 0.
We faced this issue thrice before:
1. Adding "persistent connections"
2. Adding "directory-at-once" as opposed to "one-at-a-time".
3. Adding a general "get" which figures out if a read or directory is needed
In both cases the protocol gracefully inter operates.
1. The persistence is optional in any case, and old owservers refuse it be
default (well, they return zero in that field which works the same way).
2. the "dirall" message type gives an error in old owservers, alerting the
client that that owserver doesn't support the message.
3. Same as 2
My approach would be to do the second method, add a new message that would
only be supported by newer owservers. The implementation is easy and
backwards compatible. The only issue is that a robust client would either
have to include backwards compatibility workarounds, or simply refuse to
work with older owservers.
Since there are many owservers on embedded platforms which presumably aren't
often upgraded, backwards compatibility will continue to be an issue. Simply
changing the output of an existing message to the more informative format
Doug suggests would risk silent incompatibilities.
So my real question is, given that backwards compatibility and handling of
the existing data format will have to be included in clients, is there
really a strong need for the improved read version? (i.e. the extended_read
type).
Paul Alfille
On 6/29/07, Jerry Scharf <[EMAIL PROTECTED]> wrote:
You may hate this suggestion, but IMO the way to go is option
negotiation. It's messy, adds all sorts of code, and is the only way I
know off the slippery slope you propose. I've been involved in any
number of these fire drills, and there are a couple ways I have seen it
done,
They all start with breaking the options down into areas, so known data
types could be one area and composite sensors could be another... Then
you modify the session start up to include the lowest common denominator
selection process. Then you can either have each option have a defined
name as you pass the string of known names for an area on startup. The
other is to have a version number for each area, and each version has a
known set of capabilities.
The version number is much simpler if there is not 10 different groups
writing different implementations of the protocol. The string set is
more general and used in many RFCs because of the interoperability desire.
jerry
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
