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
