device filtering support

[Vitali Lovich]

On Feb 5, 2012, at 5:25 AM, Pete Batard wrote:

> On 2012.02.05 00:34, Michael Plante wrote:
>> There's one other issue:  versioning.
> 
> Yeah, and I thought about that too.
> 
> App sends a message indicating whether it can provide a newer version of the process (i.e. a version where code has changed. If different versions use the same code, no need for action, even if app is newer version than the app that launched the enum process) during libusbx_init and if newer, the process kills itself and lets the app spawn one.
& if it's in the middle of being communicated with?  even if you have some kind of interlock mechanism, then a poorly behaving (or malicious) application can block all other applications from working.  seriously, the complexity of this is not worth the *perceived* benefit, especially since you have yet to demonstrate an actual problem that this solves.

or what if the older one has to be used for another libusb application? you can't just kill it.  & you can't know what the compatibility matrix is unless you maintain 1 manually & that's not a feasible solution. 

> 
> Oh, and APIs. You set an API for interprocess communication that's as static as the libusbx API, so you can update code and still expect old apps to work => your concern about protocol breakage is as irrelevant as concern about libusb 1.0.10 breaking 1.0.9 apps: we're of course not going to break protocols behind the scenes. Whether they belong to the user visible part or not, they would very much belong to the libusbx API. And if there's 1.0 and 2.0 libusbx apps, there might be 2 processes (but probably not if we do things well and don't need to update enum).
> 
> I did think about it and didn't identify it as a showstopper.
Relying on static APIs is great up until they need a change, & then you're up a creek without a paddle.  If you had some kind of flexible IPC mechanism (i.e. thrift, protocol buffers, json) etc, that might work, but that's adding an unnecessary external dependency.

I'm sorry, but I still fail to see the value of this whole approach.  I don't see the potential for interference with other applications that you do & I think that any slow enumeration performance on Windows (which I again haven't really seen, but to be fair I haven't really looked at it heavily) can be solved via traditional mechanisms.

-Vitali