2011/3/9 Warren Turkal <wt at penguintechs.org>: > 2011/3/9 ABC <abc at telekom.ru>
> ?What i think should actually happen is that sanei should have it's own > method for dealing with usb (and other busses) in whatever form it takes > (e.g. /dev/scanner dev file or libusb or scsi device or whatever). Sanei > should call any callbacks into the backend with a generic form for the bus > type instead of exposing it's innards. Assuming that a string is the best > form for that generic form, something like "usb:vendor_id:product_id" is > probably reasonable. ... And that suggestion does not deal with two identical scanners attached to the machine. And the 'struct' version with a single callback requires us to use enum every possible transport thru a single function in sanei, which breaks down with a backend specific transport. If a backend supports multiple transports, it can use multiple callbacks (or callback wrappers) which set the transport in the scanner struct, in addition to the opaque string. Now, this breaks down if two different transports use the same name, or if a backend treats the string as non-opaque. Though the last might be required in the case of a scanner which cannot be auto detected, like a tcp machine. I think that's the case here? allan -- "The truth is an offense, but not a sin"