device filtering support

[Pete Batard]

On 2012.02.05 20:22, Vitali Lovich wrote:
> &  if it's in the middle of being communicated with?

It never is if it uses pipes. Either a full message went out or it 
didn't. App asks the process for enum data and waits for it. If it 
doesn't receive anything it tries again. There's no acking (because 
there's no need - it's not like we're going to have to query enum data 
for transfers, or even to re-open a device that was previously open). 
And yeah, I thought about re spawning the process and detecting whether 
that's needed or not, which isn't that big a deal either.

> seriously, the complexity of this is not worth the *perceived* benefit,

I'd turn that around with "the complexity you guys *perceive* for this 
thing is leaps and bounds beyond what it would most likely be". Be it 
with shared memory or interlocking, you seem adamant at making it _look_ 
more complex than it really needs.
Excuse me for still respectfully disagreeing, since I actually went 
through an actual not too dissimilar exercise.

> especially since you have yet to demonstrate an actual problem that this solves.

The thing is, I don't really care about the problem that it solves.

If Travis and Xiaofan weren't complaining about it, as well as 
threatening to deconstruct the generic enum we have as a result, I 
wouldn't give much of a damn about potential bus pollution. In fact, I 
probably started by downplaying the problem the first time we had this 
conversation privately.

But Travis and Xiaofan are very concerned by it, therefore I am trying 
to look for a solution that satisfies them without removing some of the 
features that I want libsub(x) to provide.

Now, if everybody but Travis and Xiaofan say: "this is a non issue", 
that's absolutely fine with me.

> or what if the older one has to be used for another libusb application? you can't just kill it.

I very much can. Just like you replace a library in system32 with a 
newer one (not the part about doing it when an app is running, though I 
think Windows has mechanisms to let you do just that). We can very much 
afford the delay of a respawn on enum, because we only need it the first 
time we want to gain access to a device, and can afford a wait there. 
You guys seem to think that the process an extension of the app, whereas 
it very much isn't, and no resources are shared whatsoever. The only 
thing that exists within apps are independent copies of the enum data 
from the enum process, copies that meet a specific API which we're not 
going to change from one year to the next because there's actually not 
much to provide in terms of enum that isn't well understood right now.
Unless we change APIs, the data returned by an older process will be 
exactly the same as the data returned by a newer one. And we can of 
course create a process that returns data according to a specific API 
version if it ever changes (providing am API version during the request 
is something I'd implement by default actually)

> you can't know what the compatibility matrix is unless you maintain 1 manually&  that's not a feasible solution.

Do we maintain a compatibility matrix for libusb?

Seriously, just how complex do you think this process needs to be?

It would just feed enum data to apps. All it requires is make the 
private part of our OS specific enum data part of our API (a "private 
part" of the API if you will). Last time I checked, we only added new 
attributes to this private data - we didn't remove or change what was 
already existing. And very very infrequently. That is the _only_ part 
that needs to be common between the apps and the enum process (apart 
from hotplug events, but do we also expect to reshuffle our event 
mechanism every Tuesday?).

> Relying on static APIs is great up until they need a change,&  then you're up a creek without a paddle.

See above.

> 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.

Unneeded. It should be a lot simpler than you anticipate, therefore we 
would never need that amount of complexity.

> I'm sorry, but I still fail to see the value of this whole approach.

I see an optimized way to provide enum data and avoid duplicates. And 
especially, I don't see a _proper_ implementation of the process being 
that complex, else I wouldn't propose it. Can't say for sure unless I go 
through an actual implementation, but everything I've seen so far tells 
me it's a lot less complex than everybody else has been trying to imply 
so far. Moreover, I've had a few months to think about it, since Travis, 
Xiaofan and I started this conversation quite some time ago, and I very 
much did contemplate the process approach on regular occasions.

> I don't see the potential for interference with other applications that you do

I don't really see it either, which is something I apparently haven't 
made clear, but Travis and Xiaofan seem to see it.

But it's not because I only see something as a limited potential issue 
that I'm not going to try solving it, especially when others insist that 
it needs solving (and I see other benefits in doing so, such as a better 
refactoring of hotplug and avoidance of unnecessary re-enumeration).

Regards,

/Pete