[Nut-upsdev] upsdrv_print_ups_list and afferant reflections

[Jonathan Dion]

Hello Charles
8<--- sniping my original mail

>
> That sounds like a good idea. I was pondering how we could do this
> another way, where drivers.list is the source file, and it generates
> matching code for individual drivers, but your way allows us to
> extract information from drivers contained in binary packages.
>
Yes, it is a way to "centralize" information, and what can know which
UPS is supported by which driver better than drivers themselves ?

> I assume you would have the output parsable by your new configuration
> file library?
>
No, I don't think so. My configuration file library use the format I
exposed in my drafts (that is a tree format). If the format is perfect
for complex configuration files, I think this format is too "heavy" to
just print out and parse a simple list.

The format I thought of was :

List of supported UPSs \n  // This line to detect the begining of the list
VendorID1 \t ProductID1 \n
VendorID2 \t ProductID2 \n
...

With, eventually a variant if more "human" output is need :

VendorID \t ProductID \t More human-friendly description \n

> Another thing to consider is to have a "matching score", where some
> drivers have higher confidence that they can handle a certain VID/PID,
> but less confidence if they only match the VID. The override could be
> done by lowering the minimum required match confidence level.
>
In this system, who decide the level of confidence required to take
over the UPS ? It is too obscur for the user to let them do it, and
doing it automatically can lead to error, don't you think ?

Arnaud asks : Is it your french girlfirend that lead you to think of
such complicate ways ? (appears to be a private joke ^_^)

Arnaud though of a system of flag that enable some subdriver to claim
a UPS if only the vendor ID match. For instance, all MGE UPS are
supported by mge-hid, and all USB hardware produced by MGE are UPS.
But it could not be the case for Belkin for instance.

I think we could just make specific claim functions for subdriver we
are sure only need the VendorID (as its the case actually), and only
look the ProductID if the VendorID don't match.


Arnaud asked me too to discuse with you (and any other interested nut
dev, of course) about a "upsdrv_struct" in driver, that is a structure
that would contains :

drv_name : name of the driver
drv_vers : version of the driver
drv_maintainers : who to contact if pb with the driver
drv_authors : people xho contributed to the driver
drv_status : stable, unstable, suported by the vendor, from reverse
engineering, and so on
drv_help : an help text.

Advantage will be to have the same structure for all the driver.
Functions like upsdrv_banner (that would use drv_name and drv_vers)
will be only in the main, and drv_status will take the place of the
experimental_driver variable that was set in the upsdrv_banner
function.
drv_status could also be used for a shiny html compatibility list with
colors depending of the status of the driver.

What do you think of the idea ?

> --
> - Charles Lepple
>

Jonathan Dion