API redesign progress

[Jef Driesen]

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