[sane-devel] discussion: Future of SANE-project

[David N. Paules]

I am really confused :)
I was under the impression that the SANE project was proposing a better =
alternative to the TWAIN interface. Better, meaning that the backend is =
written once and is cross platform. That's what I understood from the =
intro page on the web-site (I pasted part of the intro here for your =
convenience).

<snippet from intro page on www.sane-project.org>
If you're familiar with TWAIN, you may wonder why there is a need for =
SANE. Simply put, TWAIN does not separate the user-interface from the =
driver of a device. This, unfortunately, makes it difficult, if not =
impossible, to provide network transparent access to image acquisition =
devices (which is useful if you have a LAN full of machines, but =
scanners connected to only one or two machines; it's obviously also =
useful for remote-controlled cameras and such). It also means that any =
particular TWAIN driver is pretty much married to a particular GUI API =
(be it Win32 or the Mac API). In contrast, SANE cleanly separates device =
controls from their representation in a user-interface. As a result, =
SANE has no difficulty supporting command-line driven interfaces or =
network-transparent scanning. For these reasons, it is unlikely that =
there will ever be a SANE backend that can talk to a TWAIN driver. The =
converse is no problem though: it is pretty straight forward to access =
SANE devices through a TWAIN source. In summary, if TWAIN had been just =
a little better designed, there would have been no reason for SANE to =
exist, but things being the way they are, TWAIN simply isn't SANE.
</snippet>

I guess without an image or in depth technical explanation, I am having =
a difficult time understanding where SANE and TWAIN operate on different =
levels, as you indicated in your message. Your message indicates that =
TWAIN is a necessary technology, but the intro page indicates that TWAIN =
is not necessary, and that SANE is the replacement.

And from the intro page, I thought that a scanner manufacturer that =
bundles 3rd-party TWAIN-compliant front-ends (OCR packages, =
Photoshop-like packages, etc.), but who wanted to move to supporting =
SANE could make the SANE backend and keep their Win32 TWAIN front-end =
for these 3rd-party software apps. Perhaps I misunderstood something =
there too.

Regarding manu. support, I wasn't thinking of formal contracts or such =
with each manufacturer. In the beginning, just publicly crediting =
companies that have contributed to various backends (even if it's only =
one scanner). But make that information easily available on the =
web-site, not burried in source code.

Until I understand how the expected roles of TWAIN and SANE (as =
architected in SANE, its roadmap, etc.) I cannot argue my points about =
simply making the web-site contain more information about the =
importance, benefits, momentum, and support of the SANE project. If you =
could take a moment, I'd appreciate it. There are many components in =
talking to a scanner, and I don't see how they all fit together.
1. driver (OS and scanner chipset dependent),=20
2. connection protocol handler (USB, SCSI, TCP/IP, Bluetooth?)
3. TWAIN?
4. SANE?
5. Applications

If you have a moment to draw out the ideal setup, I'd appreciate it.
Thanks,
Dave Paules

> -----Original Message-----
> From: Major A [mailto:andras@users.sourceforge.net]
> Sent: Sunday, July 11, 2004 12:16 AM
> To: David N. Paules
> Cc: SANE devel
> Subject: Re: [sane-devel] discussion: Future of SANE-project
>=20
>=20
>=20
> > But, if the ultimate goal of SANE is to supplant TWAIN as the
> > standard for accessing image devices, shouldn't more effort be put
>=20
> I don't think it is. TWAIN and SANE act on completely different
> levels. I suppose that once a sufficiently large number of
> manufacturers support SANE with their code (binary or open-source),
> they will begin to see that there's no point in wasting time and money
> writing a separate Windows/MacOS driver, they will just use SANE on
> these platforms too, with the cross-platform SANE backend they had to
> write anyway (possibly with their own frontend optimized for their
> scanners). TWAIN is still going to be the interface between the
> frontend and the application the image is to be imported to.
>=20
> > 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.
>=20
> I don't think we can do a lot at the moment. There's no update path
> from TWAIN to SANE that I can see, and you can't tell who the
> techno-geeks in a company are without having had prior contact with
> them. I think that more and more developers of proprietary software
> realize that open-source can save them money and effort and create
> superior products (they already see that the first time they pop that
> Knoppix CD into their Windows computer), so it's only a matter of time
> before they start lobbying within the company.
>=20
> > 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.
>=20
> That sounds a bit like Darl McBride to me. I don't think any of us
> hobbyist SANE developers have the financial and legal backing needed
> to claim any heavyweight industry support.
>=20
> > 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.
>=20
> That's how all open-source projects start out, just like Linux, GIMP,
> etc. Look at what's become of them, I'm quite confident that SANE will
> have a similar future.
>=20
>   Andras