Perhaps I misunderstood SANE's goals. From what I've seen, the backends = do not dictate what the front-ends look like, only their capability. I = don't understand why the bluster about multiple front-ends and more = control over the gui. I was under the impression that one sane backend = for a device will support multiple applications (front-ends) such as = image capture, OCR, digital camera photo image acquisition, video = acquisition from a digital camcorder, etc.
Besides, the SANE project is open for review/suggestions for = enhancement, so why not get some feedback from scanner makers on what = makes SANE a non-option for the future? What 'minimum requirements' are = missing from the current architecture? I can see your point about GPL'd backends. I agree it is easier to debug = and extend them. But here's my point: Do you want to be the one always = repairing and fixing scanners to work with SANE? Or do you want all the = manufacturers to feel responsible for ensuring SANE compliance? If SANE = is architected intelligently (i.e., backwards compliance with older = backends), open source backends may not be necessary. The manufacturers will currently see the SANE org as a free resource for = reaching other markets they didn't officially target (i.e. the *nix = markets). There is no urgency or requirement for them to support SANE = just because the project is open source. In fact, that is the number one = reason they will NOT be concerned. 'Those hackers at SANE-project.org = will make my device compliant with their software. And I don't have to = pay for it.' But, if the ultimate goal of SANE is to supplant TWAIN as the standard = for accessing image devices, shouldn't more effort be put on making SANE = the future standard. This route will cause scanner makers and their = support network to conciously choose to either support or not support = the new standard. The SANE project's developers should then concentrate = on enhancing the architecture, ensure backwards compatibility, create = and market compliance badges, create plugins for Adobe products (like = existing TWAIN plugins), etc. and not write new backend modules for each = new device that comes on the market. Perhaps working examples demonstrating how scanner makers can leverage = their investment in TWAIN support while migrating to SANE might be = useful for getting scanner makers to take notice of SANE. If an upgrade = path was readily shown, techno-geeks at the manufacturer might prefer = and sell the SANE idea to managers within the company. Formal propoganda of industry heavyweight support (a consortium of = scanner makers and front-end application development houses) on the = web-site might make other makers feel the need to join in. Without this kind of direction, I simply see SANE as being a = hobbyist-level effort which is why I questioned the future of it. Thanks = for listening and answering my questions. Dave Paules Quantum Leap Innovations > > m. allan noah wrote: > > > it is important to remember that the developers of sane=20 > are volunteers=20 > > > just like you. most of us got involved because we had a=20 > lame scanner too.=20 > > > we probably dont have time for such evangelism. > >=20 > > But if someone was offering.... >=20 > sure, sure. i got no problem with someone acting as a liason=20 > to hardware=20 > vendors. i do this myself with fujitsu. >=20 > > > that said, even if someone had the time to run around and=20 > convince vendors=20 > > > of the merits of sane, there would be at least two=20 > recurring sentiments: > > >=20 > > > 1. sane spec is not complete, cause it does not support various=20 > > > LEDs,buttons or sensors that the manufacturers believe=20 > add so much value=20 > > > (and brand distinction) to their products. > >=20 > > Proposals to include this have been discussed, possibly=20 > input from a=20 > > manufacture would help. >=20 > sure, and none of us ever had the time to actually formallize the=20 > proposal, let alone get input from manuf. >=20 > > > 2. they are going to want more control over the gui so=20 > they can do things=20 > > > like show pictures and diagrams of the scanner, which=20 > means they are going=20 > > > to write their own front-end half the time. > > >=20 > > Or repackage existing - under GPL - is this a problem. >=20 > a plethora of front-ends is not a problem, but it does defeat=20 > some of the=20 > point for the vendor who is also making a backend. >=20 > > > then, i as a developer, and hopefully you as an=20 > open-source/free software=20 > > > user would have another complaint: > > >=20 > > > 3. closed-source backends are much harder to debug/extend=20 > than free, even=20 > > > if you have the vendor to complain to. > > >=20 > > This is looking for problems, why assume they will be closed source. >=20 > because experience shows that they will be, esp. in the=20 > cheaper hardware=20 > segments, where the vendors are likely to cross-license tech=20 > from each=20 > other (think winmodems). >=20 > > > that said, there are a couple vendors who do make=20 > backends (brother comes=20 > > > to mind).=20 >=20 > i can say that some vendors, (fujitsu) have been quite=20 > talkative about=20 > their products, and i have specs for many of them, without=20 > signing NDA,=20 > and whatever code i write is at no cost to them or you, and=20 > under the GPL.=20 > seeing more of that would be great. >=20 > allan >=20 > --=20 > "so don't tell us it can't be done, putting down what you don't know. > money isn't our god, integrity will free our souls" - Max Cavalera >=20 >=20
