On 2012-06-22 13:51, Jef Driesen wrote:
- Add device enumeration support.
With the new device enumeration support, applications can now enumerate all the supported devices at runtime, and don't have to maintain their own list anymore. The api uses an iterator style interface. See universal.c for some example code.
I noticed two possible "problems" with the new device enumeration api. Right now each device is identified by means of its name (with a vendor and product part) and model number. (There is also the family type, but that's irrelevant for this discussion.) Because it's the combination of both fields which should be unique, there can be two slightly confusing cases:
1. Devices with the same name, but different model numbers.
This should be rare, but can happen when there are multiple variants of a particular device. The only example that exists today is the Oceanic OC1. There is a variant with model number 0x434E and one with 0x4449.
Having two devices with the same name might be a bit annoying. In a typical application only the name will be displayed, and thus the end-user would see a duplicated entry. Note that for the Oceanic's, the actual model number isn't necessary for downloading, so both entries would work equally fine and the application could hide the duplicate entries. However I can't guarantee that will always be the case.
Removing the duplicated entries from the library isn't really an option either, because then reverse lookups won't work anymore. Assume a user owns an OC1, but selects another model from the same family, for example the Atom 2.0. Downloading will work fine, because internally the backend will autodetect the correct model, and report back the correct model number to the application. The application could then (but that's entirely optional) lookup the associated name based on the model code and the family type. But of course this reverse search will only work if the duplicate entries are still there.
2. Devices with a different name, but the same model number.
This can happen when identical devices are sold under a different name (e.g. rebranded models), or when a newly introduced variant is fully backwards compatible with previous variants and shares the same model code. An example of the first case are the Aladin Air X series, which were renamed to Aladin Air Z. Examples of the second case is the HW OSTC, which exists in 3 variants (OSTC, MK2 and 2N).
For the end-users it's probably convenient to have these "duplicate" entries, because they may not be aware they are in fact the same device. However for a reverse lookup, it means all entries will match and you end up with multiple candidates instead of an exact match.
Definitely not a major problem, but something you might notice some day.
Jef