sane-project-website/old-archive/1999-08/0109.html

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