----- Forwarded message from 252353N@knotes.kodak.com -----
Return-Path: <252353N@knotes.kodak.com>
From: 252353N@knotes.kodak.com
To: Andreas Beck <becka@rz.uni-duesseldorf.de>
Message-ID: <852567CA.007047E6.00@knotes.kodak.com>
Date: Wed, 11 Aug 1999 16:34:57 -0400
Subject: Re: Starting a discussion about SANE and TWAIN...
From: Mark McLaughlin
Hi Andy...
Many thanks for your reply...
I agree with your first comment. Linux, especially, is attracting
all kinds of attention, and while I think it is essential to support
UNIX and not just Linux, I suspect that the best short term goal
is getting TWAIN on Linux.
Your comment about abstaction layers is of keen interest to
me. I'm not just interested in seeing TWAIN on UNIX. I think
there is an opportunity with SANE to create a driver development
'kit' that abstracts away the physical communication with the OS,
rather like ASPI does, though I'd like to see something less wire
dependent.
Perhaps such an abstraction already exists, if not it needs to,
since it would significantly reduce the effort of porting drivers from
one OS to another, which is the main reason you see so many
devices well supported on one platform and weakly supported
or unsupported on others.
In this case it would then be highly desireable to see SANE
on Macintosh and Windows platforms, since it would reduce
the driver development effort.
As for your comparison of SANE and TWAIN, here are some of
my observations...
- SANE is GUI-less to provide optimal support across networks
and on systems were there is no Windowing system.
- TWAIN assumes the presence of a Windowing system (which
is pretty reasonable for Windows and Macintosh, and for a
lot of UNIX systems). The reason for the GUI is that it takes
away the burden of capability negotiation from the application
writer. This means that an app writer can communicate with a
Source with a minimum number of calls, without losing access
to all the features of the device represented by the Source.
- I'm going to say that last bit again in a different way, since it is
an important part of the TWAIN philosophy. When we are
working on the TWAIN specification, we often ask the question
"does this make things easier for the Source writer or for the
application writer?" Whenever possible we try to make things
easier for the application writer, since there are many apps for
every Source.
- And having said that, let me say that TWAIN has been and is
continuing to emphasize the programmatic side of the interface.
This is because some application writers really hate those
internal TWAIN GUIs, and want to assume full control of the
Source. It's an ongoing process to convince Source writers to
take the time to fill out both interfaces.
As I've stated in my other mail messages today, I believe the
immediate win from seeing SANE and TWAIN on UNIX, Windows
and Macintosh platforms is that it removes an impediment from
application writers who want to try their hand on another platform
without massive code rewrites.
In the case of TWAIN that means that a Windowing system must
be present. And on UNIX that really points the finger at X-Windows.
Of course, the cool thing about X is that it can display windows
across the net, so the fact that TWAIN requires a GUI does not
preclude the use of remote capture devices.
For the time being I recommend that we not worry about running
TWAIN on console mode systems. TK/TCL could be used to
accomodate this, but if my initial assumption is true, that the first
targeted developer audience is application ports, then there
won't be anyone interested in running TWAIN on a system that
isn't also running X. There is nothing preventing us from looking
into this later, if a real need is identified (I realize that some remote
scanning solutions might be 'very' interested in this).
As for the look of the different TWAIN GUIs...
Well...
Heh...
We've had chats in the Working Group about this, and are aware
that the plethoria of interfaces isn't ideal at all points. It is ideal in
that it allows a hardware vendor to present their device the way
they want (which presumably accesses all the features of the
device). Those applications that want to write their own GUI
interfaces do so to let them integrate the control of the image capture
device into their own 'look and feel' and to eleminate operator
retraining.
We've discussed the notion of a single, standard interface that
applications could invoke as an alternative to the Source's GUI
and to writing a complete programmatic interface. This path
looks nastier the longer one looks at it so we've shelved it for
now, but if the SANE group has ideas on this, we're more than
happy to dust off the issues and chat about them again...
I realize that I may not have addressed all the items in your
message to me, but I also just noticed that I have to leave, so
I'm sending this out now. Please let me know if I missed anything
that you want to discuss more...
Mark McLaughlin
Eastman Kodak Company
716 726 1352
mlm@kodak.com
----- End forwarded message -----
I cut out the original mail from me, that is referenced above, as you should
already have it.
Cu, ANdy
-- = Andreas Beck | Email : <andreas.beck@ggi-project.org> =
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com