Tom Li <[email protected]> writes: > There seems to be a misunderstanding here. The original proposal doesn't > change ups.status=OL at all. Instead, it merely appends an additional > keyword "ECO" after "OL", i.e. ups.status="OL ECO". Since ups.status > is already a space-separated list of keywords [1]. It doesn't involve any > breaking change, everything will continue to work as usual.
I had no idea about the space-separated keyword list. I wrote python code, not yet published, that compares to "OL". I was suggesting that changing the contens would break code that didn't know about the new one, and I guess that has turned into "may break code that wasn't expecting this". > Instead, the motivation of using the keyword "ECO" is to maintain the > existing behavior - I looked around the codebase and found some drivers > [2] already use the flags "OL" & "ECO", so I thought it was a good idea > to simply make it a documented and standard behavior. > > [1] Currently we already have "OL", "OB", "LB", "HB", "RB", "CHAG", > "DISCHRG", "BYPASS", "CAL", "OFF", "OVER", "TRIM", "BOOST", "FSD", > and a huge number of possible combinations. I really should read the specs then :-) But I suspect I'm not the only one with code/scripts like mine. > [2] I rechecked and found it was actually only used by a single driver, so on > second thought, maintaining the existing behavior is not really a concern, so > I agree, a new variable can be an alternative solution if there's consensus. I don't think it's a big deal either way. In general I prefer simpler variables that abstract more complicated behavior so that less sophisticated data consumers will end up doing somethin sensible. But I see that the existing status variable is not like that.
signature.asc
Description: PGP signature
_______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
