[sane-devel] How to handle devices with multiple USB bulk-in endpoints

[Reinhold Kainhofer]

Am Dienstag, 2. November 2010, um 01:24:38 schrieb m. allan noah:
> I've not had a chance to look at the code, but i can say that this
> design is preferred over a new argument to the open() function,
> because some scanner might someday require communication with two
> endpoints of the same type concurrently.

Actually, I meant whether we should additionally provide a way to globally 
override the default endpoint. Most devices use only one endpoint, so it 
doesn't make so much sense to require their backends to provide the endpoint 
to each and every USB command. Rather, one would pass the endpoints to be used 
to the open function and those will be set as default.
Of course, with each individual USB command, one can override that default 
(which is only relevant for devices that use multiple endpoints for different 
operations).


> Also, sanei is 'internal' to sane. The interface is not stable, and we
> don't want it installed to the system. In fact, if we wanted to, we
> could just use your new functions in place of the old ones, and modify
> all the backends to use the -1 argument, without harming external
> development.
> 
> So, the bigger question is, why are you not installing your backend
> using the infrastructure that sane gives you?

Well, in the end I think the backend should be included with the stock sane-
backends repository. However, I don't think that each new backend development 
process should start inside sane-backends for several reasons:

1) One never knows if a developer will really finish the backend (or at least 
get it to a usable stat), so cluttering sane-backends with half-finished, 
broken backends in development is not an option.

2) I want to provide a repository for others to try out the backend (and only 
that backend) while still in development.

3) During development, I wasn't sure which additional libraries would be 
required or which external code would be incorporated (in particular for SNMP 
detection in my case). I was also investigating the code from the CUPS 
project, which is GPL, but owned by Apple, so I doubt that the SANE exception 
(which AFAIU is needed for the backends in sane-backends) would be granted.

4) In particular for new backends, there will be users (larger institutions 
with managed installations) that want to use the backend with older sane 
versions.

So, in short, I think that new backends should start in their own repository 
and can then later be incorporated into sane-backends. However, for this, one 
needs to copy (and continuosly sync) sanei from sane-backends to one's one 
repository. After all, sanei provides utility function for all the basic 
functionality common to most backends.

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org