Nut upsdev - Jun 2017 - new driver- or vendor-specific variable prefix?

Not to pick on anyone in particular, but for the sake of organization, I think
we might need to address the need for variables beyond the standard ones defined
here:

   http://networkupstools.org/docs/developer-guide.chunked/apas01.html

From
http://networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_variable_names
:

"PLEASE don?t make up new variables and commands just because you can. The
new dstate functions give us the power to create just about anything, but that
is a privilege and not a right. Imagine the mess that would happen if every
developer decided on their own way to represent a common status element."

On the other hand, it is useful to expose everything that comes out of the stub
driver generator to see if it is useful. And for the UPSes where we don't
have good documentation, well... I'm guilty of this, too:

  
https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L613

Any thoughts? Does "ups.debug.*" work? Just "debug.*"?
"vendor.XYZ.*"?

Here are the two pull requests that prompted this email:

 * https://github.com/networkupstools/nut/pull/431
 * https://github.com/networkupstools/nut/pull/440

Hi Charles

2017-06-07 3:42 GMT+02:00 Charles Lepple <clepple at gmail.com>:
> Not to pick on anyone in particular, but for the sake of organization, I
> think we might need to address the need for variables beyond the standard
> ones defined here:
>
>    http://networkupstools.org/docs/developer-guide.chunked/apas01.html
>
> From http://networkupstools.org/docs/developer-guide.chunked/
> ar01s04.html#_variable_names :
>
> "PLEASE don?t make up new variables and commands just because you can.
The
> new dstate functions give us the power to create just about anything, but
> that is a privilege and not a right. Imagine the mess that would happen if
> every developer decided on their own way to represent a common status
> element."
>
> On the other hand, it is useful to expose everything that comes out of the
> stub driver generator to see if it is useful. And for the UPSes where we
> don't have good documentation, well... I'm guilty of this, too:
>
>    https://github.com/networkupstools/nut/blob/
> master/drivers/tripplite_usb.c#L613
>
> Any thoughts? Does "ups.debug.*" work? Just "debug.*"?
"vendor.XYZ.*"?
>
2nded!

there are 2 different use cases here:
- vendor.xyz would be valid for specific vendor things in production.
however, our approach is that any such things can have a name useful for
others too.
so that would probably limit that point to "opaque" features (I once
talked
or at least though of using a vendor.xyz collection to access the ups
internals...)
* ups.debug (or preferably debug.xyz) can be transiently useful to get
visibility on data (through upsc dumps) to finalize a new driver
development or further evolution. That could even be used in conjunction
with a driver generic flag (or maybe -D) to enable or trim out these

Here are the two pull requests that prompted this email:
>
>  * https://github.com/networkupstools/nut/pull/431
>  * https://github.com/networkupstools/nut/pull/440
>
not looked at these thoroughly yet, but #431 tends to expose raw HID data
as nut data.
I'm not in favor of these! Most of these HID data are either used in other
HID subdrivers (thus, references available) or to be considered for
dropping or for the debug.xyz collection...

cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20170613/11a4312a/attachment.html>