HAL 0.1 release

[Havoc Pennington]

On Thu, 2003-10-09 at 16:27, Eric Gillespie wrote:
> The current format we use is structured.  What you are suggesting
> presents an extensibility problem.  Every time you want to
> support a new bus you have to account for new attribute names.  A
> vendor ID is a vendor ID regardless of which bus it identifies a
> vendor on.
> 

To me the right way to do this is that you have a separate property for
each semantic purpose:

 USBVendorID
 PCIVendorID
 VendorID
 LocalizedVendorName

USBVendorID is defined to be the vendor ID read from the USB hardware.

PCIVendorID is defined to be the one from the PCI hardware.

VendorID might be defined to be the canonical/best/portable vendor ID to
use as a key when associating all devices from the same vendor.

LocalizedVendorName might be defined to be the vendor name to display to
the user.

If you define the generic VendorID to be for machine sort you want to
canonicalize it, for example you might always use the same string for
"SGI"/"Silicon Graphics"/"SGI, Inc." all go to -> "SGI." This way a
program can use it reliably as a key.

LocalizedVendorName would be defined to vary by locale, on the other
hand.

If you conflate these different semantics, you could get some apps
expecting VendorID to be exactly what the bus said and some expecting it
to be a reliable sort key, for example. At that point say you have the
"SGI" example above, with only a single property you have to leave one
of those apps broken, you can't make it work for both of them.

VendorID is just an example, I have no idea if the above even makes
sense for VendorID, but hopefully the general principle I have in mind
makes sense.

Havoc