[Nut-upsdev] upsdrv_print_ups_list and afferant reflections

[Charles Lepple]

On 8/2/06, Jonathan Dion <dion.jonathan at gmail.com> wrote:
> 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

At the very least, I think it should be a key-value sort of thing, like this:

VendorID: 0x1234
ProductID: 0x5678

We are trapped in the same sort of non-expandable situation as with
drivers.list if it is just tab-delimited.

However, we could have a header column for tab-delimited stuff, as
long as we don't hardcode assumptions about column numbers.

> > 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 ?

Well, maybe we should just use that for printing out the list of other
possible drivers. tripplite_usb can currently refer people to
newhidups if it's not the serial-over-USB hack that tripplite_usb
does, and this could be generalized.

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

I was going to suggest an XML-based system using XSLT stylesheets to
make the compatibility list, but I showed restraint :-)

> 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.

Not sure I follow this logic.

> 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 ?

Sounds cool, but an expandable structure like this seems to reinforce
my comments above about key-value lists.

-- 
- Charles Lepple