device filtering support

[Pete Batard]

On 2012.02.06 02:19, Michael Plante wrote:
> Pete Batard wrote:
>>> - Xiaofan and Travis see the alleged pollution from our current enum
>>> process unacceptable, even if done once per app (because launching a new
>>> app would still pollute =>  eliminated a threaded approach)
>
> I'm going to have to side with Vitali here again:  show me the benchmarks,
> and also consider how often such enumerations actually happen in practice.
>
>
>>> This data will be copied over into the same device structure we used, so
>>> the only thing it might break is apps that were poking around the enum
>>> list (and even then, we will still need some form of list to be kept
>>> internally).
>
> Or if the format changes on our end.  Ever.  Period.

Format that is part of our API, albeit internally.

If you want to consider it another way, we're doing a read-only version 
equivalent of /sys/bus/usb props in sysfs. Except the format we use to 
provide data is the same as what we use for libusbx.
Anybody knows the last time there was a breakage for apps that looked 
into sysfs for USB properties. Sure was a bitch the day the Linux devs 
decided to go with /sys/bus/usb/devices/usb1/idProduct in replacement 
for the perfectly fine /sys/bus/usb/devices/usb1/PID, and did that on a 
whim because they thought the name looked better...

Why should be be any less cautious than Linux there and alter existing 
data that we used to provide that is for the most part based on a spec 
that is meant to be backward compatible? Can you highlight a scenario 
where we potentially might have to do that? Most of the data comes from 
USB specs, and I don't exactly see them breaking compatibility, and the 
rest is OS accessors, such as paths, that can change from one day to the 
next (/dev/usb1 -> /dev/usb/1) without impairing us as long as the OS 
access APIs stay the same.

> Consider four alternatives:
>
> 1) statically linked (or private dll), thread approach
> 2a) system32 shared dll, thread approach
> 2b) statically linked (or private dll), process approach
> 2c) system32 shared dll, process approach

You do know that all our shared libraries have a version number suffixed 
to them right? Why shouldn't we change that version number when our 
process communication API changes?
Or does breakage in a non public part of an API not follow the same 
considerations as breakage in the public part?

=> as long as newer libraries supersede the inter process API, they use 
the same version (eg -1.0) and your 15 year old libusbx 1.0.10 app will 
still works with 1.0.5748 (because I doubt we'll have had 5738 supersets 
of the interprocess APIs that we need to be aware of, and we can easily 
handle the few we'll have)
If there's API breakage, be it for private or public part, then you have 
libusbx-1.0 and libusbx-1.1, and your 15 year old app still works 
(unless -1.0 has not been installed, in which case your user will have 
to fetch it itself). This is why I said our interprocess data format 
would be part of the API, and therefore subjected to the same constraints.

As far as  know, it's the same problem as with any shared library. If 
it's not a superset, it's going to break apps, so you gotta leverage 
versioning and install 2 libraries if needed. Happens all the time. And 
yes, just like you can have 2 concurrent libraries in system32 servicing 
different incompatible versions of the API, you can end up with 2 
processes servicing 2 different versions of the inter process API, which 
is also perfectly fine. And, once again, if anything, the interprocess 
API is expected to introduce breakage a lot less often than our public 
API is.

Or am I still missing something?

Regards,

/Pete