[Nut-upsdev] upsdrv_print_ups_list and afferant reflections

[Jonathan Dion]

Hi !

On 8/2/06, Charles Lepple <clepple at gmail.com> wrote:
> 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.
>
Ok, I see your point about the non expandable situation. I prefer the
first way you proposed :

VendorID: 0x1234
ProductID: 0x5678

than a column based output, because if some value don't have the same
length, it become quickly unreadable.

Would something like  :

List of supported UPSs
===
VendorID: 0x1234
ProductID: 0x5678
===
VendorID: 0x9012
ProductID: 0x3456
ProductInfo : All UPS of XX vendor
===
.
.
.

I though again about using my new parser and format for that. It would
become something like :

#List of supported UPSs
supported_ups (
      mge-hid1 (
            VendorID = "0x1234"
            ProductID = "0x5678"
      )
      mge-hid2 (
            VendorID = "0x9012"
            ProductID = "0x3456"
            ProductInfo = "All UPS of XX vendor"
      )
      belkin-hid1 (
            VendorID = "0x1234"
            ProductID = "0x5678"
      )
      ...
)

The advantage is that the parser exist (I just have to create a
entrance point that parse stdin and not a file, it is easy and quick),
and that it make a tree structure that is easy to manipulate. (and you
can add any information you want, it is absolutly expandable) We also
have information about which subdriver supporte which product.

What do you think of it ?


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

The idea is that for mge subdriver for instance, you don't really need
to look at the Product ID as it support all MGE USB UPS. But perhaps
in the future it would be able to support others UPS than MGE's ones.
I would want ot make claim function as exhaustive as possible, so if
you want to add any (VendorID, ProductID) to the supported list of any
subdriver, you just have to add an entry in the supported list, and
don't need to go verify if the claim function would effectivelly claim
it.

Peter wrote :
When I designed the claim function, I made it a function on purpose
(rather than a data structure). The reason is that there will
invariably be future cases where compatibility cannot be decided based
on simple pre-set criteria, such as vendorId and productId.

I understand this point and see that there can be problem in the futur
if we use only a data structure. It is why I propose to mix the two.

For the need of the print_ups_list, we need to have a data structure
containing the two IDs, and for the moment I believe that those two ID
are sufficient to choose the subdriver to use, right ?
So let's use this data structure. But as we still use the claim
function, we still can add exception case if the problem appears in
the futur.

This way in the most common situation, we just have to add an entry to
the data structure (easier to maintain, don't make the claim function
grow and keep it clear), and we still can manage exception case.

Peter wrote :
The reason I did not add ProductId's to all the claim functions was
because I did not want to break drivers that previously worked. We had
never compiled a complete list of ProductId's for a given vendor.

Yes, it is a problem. We need this list for hal for instance. Perhaps
should we wait to have such a list to modify the claim functions, and
let them as they are for the moment.

Peter wrote :
A "subdriver" argument would be
sufficient. It would be easy to modify the "claim" mechanism. However,
when doing this, subdrivers should get nicknames, i.e.,
"./newhidups -x subdriver=apc" would look a lot better than
"./newhidups -x subdriver=APC/CyberPower HID 0.9".
Also, if the user selects a subdriver that doesn't exist (or --help),
a list of available subdrivers should be printed.

Yes, I totaly agree with that, as for the subdriver argument, as for
the nickname for subdriver and as for the list of available subdriver
^_^
It can be a way to solve problem if we use the data structure in the
claim list and forgot to add a product ID to the list.

Do you think this approach (to use the data structure in claim
function) is good or do you prefer to let the claim function as they
are and only use the data structure for print_ups_list ?



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

Peter wrote :  (sorry if I don't follow the order)
I don't see how this last one (the compatibility list) can be
generated from the vendorId and productId. Shouldn't compatibility be
based on devices that have been reported to work by users, rather than
what the driver writer thought? Some manufacturers use the same
productId for many different devices, some of which work better than
others.

Yes, you are right, I messed up there. compatibility list cannot be
made just from the two ID. This idea was to be put with the last part
of my first mail, with the driver information structure.
Arnaud would like to have different colors for the driver column to
make clear the driver status in the compatibility array. The making of
this array would be done by the same tool, but it will not use the
print_ups_list of the driver, or at least not if it only contains ID
information.
But if it also contains name of the UPS, if an user report an UPS to
work with a driver, we add the UPS to the list in the driver, and we
just have to use the tool to generate the new compatibility list

The goal is to centralize data somewhere, and to make a tool that can
automatically extract and use those data. Then, we just have to add an
UPs in a driver and the tool will update all the others files that
contains this information

Waiting your reactions ^_^

Cheer

Jonathan Dion