On Mar 11, 2012, at 8:26 PM, Greg A. Woods wrote: > I don't ever want to support mis-matched installs -- I just want to make > sure the system will fail to a safe state in the case where there is an > accidental mis-matched install.
Agreed, as far as internal interfaces go. Hence my initial concern about the bit masks - but that's not what I'm referring to now. > In order to do that though we should first discuss how to put explicit > version identifiers into the internal protocols. I didn't expect I > would be able to do that all in the span of adding support to meet my > new unique requirements, so I designed changes to the internal protocols > in such a way that they would be independent of existing features. I guess we have traditionally considered the TCP interface to be an "external protocol", in that it is documented, and less likely to change in structure. With NUT being embedded into NAS firmware, as well as being packaged in distributions that are slow to upgrade, the possibility for version skew is great. > Note that what I've just said here is to be added to what I've already > said about the need to avoid overloading identifiers in protocols and to > avoid removing or usurping useful features. Depends on your definition of "fail to a safe state", then. Overloading "FSD" (by setting it in addition to a newer, more specific shutdown flag) ensures an older upsmon will see the shutdown intent of the EPO or DYING action - otherwise, it won't recognize the need to shut down. Let's put that issue aside for a moment. If we're going to add something to the protocol that explicitly indicates client/server compatibility, I don't think it should be a version number - I think it should be more of a "has feature X/needs feature Y" thing. Plus, if there is an old vs. new incompatibility, there should be a way for a user to turn that error into a warning. The degenerate case of "needs feature" failing is that an old upsd returns a NUT_ERR_UNKNOWN_COMMAND response, which should work well with existing servers. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
