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

<!-- received="Thu Aug 12 12:54:54 1999 PDT" -->
<!-- sent="Thu, 12 Aug 1999 20:55:52 +0200" -->
<!-- name="Andreas Beck" -->
<!-- email="becka@rz.uni-duesseldorf.de" -->
<!-- subject="Re: Starting a discussion about SANE and TWAIN..." -->
<!-- id="" -->
<!-- inreplyto="852567CA.007047E6.00@knotes.kodak.com" -->
<title>sane-devel: Re: Starting a discussion about SANE and TWAIN...</title>
<h1>Re: Starting a discussion about SANE and TWAIN...</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:55:52 +0200</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#111">[ date ]</a><a href="index.html#111">[ thread ]</a><a href="subject.html#111">[ subject ]</a><a href="author.html#111">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0112.html">Petter Reinholdtsen: "Unexpected Win32 success story"</a>
<li> <b>Previous message:</b> <a href="0110.html">Andreas Beck: "Re: Starting a discussion about SANE and TWAIN..."</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>
<!-- body="start" -->
<i>&gt; I agree with your first comment.  Linux, especially, is attracting</i><br>
<i>&gt; all kinds of attention, and while I think it is essential to support</i><br>
<i>&gt; UNIX and not just Linux, I suspect that the best short term goal</i><br>
<i>&gt; is getting TWAIN on Linux.</i><br>
<p>
Yes. Though all Unixes are more or less alike, it will be an almost zero<br>
effort to have it on all Unixes, then.<br>
<p>
<i>&gt; Your comment about abstaction layers is of keen interest to</i><br>
<i>&gt; me.  I'm not just interested in seeing TWAIN on UNIX.  I think</i><br>
<i>&gt; there is an opportunity with SANE to create a driver development</i><br>
<i>&gt; 'kit' that abstracts away the physical communication with the OS,</i><br>
<i>&gt; rather like ASPI does, though I'd like to see something less wire</i><br>
<i>&gt; dependent.</i><br>
<i>&gt; </i><br>
<i>&gt; Perhaps such an abstraction already exists, if not it needs to,</i><br>
<i>&gt; since it would significantly reduce the effort of porting drivers from</i><br>
<i>&gt; one OS to another, which is the main reason you see so many</i><br>
<i>&gt; devices well supported on one platform and weakly supported</i><br>
<i>&gt; or unsupported on others.</i><br>
<p>
Yes. This is exectly, why sane includes the sanei_* interfacing files that<br>
abstract the paths to the hardware.<br>
<p>
<i>&gt; In this case it would then be highly desireable to see SANE</i><br>
<i>&gt; on Macintosh and Windows platforms, since it would reduce</i><br>
<i>&gt; the driver development effort.</i><br>
<p>
Yes. Adding an ASPI layer for SANE should IMHO be no big deal. Generic SCSI<br>
support is there for the Unixes in some flavours, so I assume adding in<br>
ASPI shouldn't be a big deal.<br>
<p>
I see more problems on the common "ad-hoc" interfaces that were invented,<br>
like using the parallel port, or the serial port in nonstandard ways.<br>
I have heard of at least one scanner that uses the serial port modem control<br>
lines instead of the data lines to transmit data.<br>
<p>
We should make up standard APIs for accessing:<br>
<p>
- the SCSI-buses of the host system<br>
- serial ports (used in the "normal" way).<br>
- parallel ports<br>
- USB<br>
<p>
Most other methods (homebrew interface cards and such) aren't in common use<br>
anymore these days.<br>
<p>
<i>&gt; As for your comparison of SANE and TWAIN, here are some of</i><br>
<i>&gt; my observations...</i><br>
<p>
<i>&gt; -   SANE is GUI-less to provide optimal support across networks</i><br>
<i>&gt;     and on systems were there is no Windowing system.</i><br>
<p>
Yes and no. SANE does have GUIs (two of the three existing SANE frontends<br>
are graphical), but the GUI is not tied to the scanner.<br>
<p>
It is possible to write customized GUIs that work with only one scanner<br>
and can be tweaked to the manufacturer's liking.<br>
<p>
<i>&gt; -   TWAIN assumes the presence of a Windowing system (which</i><br>
<i>&gt;      is pretty reasonable for Windows and Macintosh, and for a</i><br>
<i>&gt;      lot of UNIX systems).  The reason for the GUI is that it takes</i><br>
<i>&gt;      away the burden of capability negotiation from the application</i><br>
<i>&gt;      writer.  </i><br>
<p>
Yes. This is what we should add to SANE in a generic manner. The existing<br>
frontends are capable of interfacing with the most well known photo-retuche<br>
software for Unix, the GIMP, but not much else.<br>
<p>
Due to Unix' piping facilities, you can feed most software directly from a<br>
File-like stream, so not many people see too much need for other mechanisms.<br>
<p>
However it would be nice, if we could add an API to the frontends we have<br>
that will allow them to export a simple TWAIN-like "Acquire Image"<br>
interface.<br>
<p>
So it would look like this:<br>
<p>
application -&gt; TWAIN-API -&gt; TWAIN_2_SANE frontend remote control interface<br>
-&gt; SANE frontend -&gt; SANE backend.<br>
<p>
This gives the best of both worlds:<br>
<p>
The application uses the simple but small and efficient TWAIN API, which is<br>
well known and thus no problem to implement for most programmers.<br>
<p>
We write a TWAIN_2_SANE glue layer, that handles communication with the<br>
SANE frontend, which display the GUI, lets the user press his buttons and<br>
hands back image data to the application.<br>
<p>
The sane frontend communicates with its backend as usual.<br>
<p>
<i>&gt;      This means that an app writer can communicate with a</i><br>
<i>&gt;      Source with a minimum number of calls, without losing access</i><br>
<i>&gt;      to all the features of the device represented by the Source.</i><br>
<p>
Yes. However, tying the GUI into the driver itself means, that you have to<br>
heavily modify the driver for each GUI. GUIs differ very much in their<br>
method of communicating with their client programs, what often requires <br>
large source code changes to accomdate different programming methods that<br>
are to be preferred for the different GUIs.<br>
<p>
This is why I suggest that extra layer. The GUI gets insulated in the<br>
SANE frontend.<br>
<p>
This allows to - for starters - write one single X11 GUI and be done with<br>
it. All the manufacturer really needs to deliver is the backend.<br>
<p>
The application-&gt;TWAIN-&gt;frontend patch can be done with standard<br>
components.<br>
<p>
<i>&gt; -    I'm going to say that last bit again in a different way, since it is</i><br>
<i>&gt;      an important part of the TWAIN philosophy.  When we are</i><br>
<i>&gt;      working on the TWAIN specification, we often ask the question</i><br>
<i>&gt;      "does this make things easier for the Source writer or for the</i><br>
<i>&gt;      application writer?"  Whenever possible we try to make things</i><br>
<i>&gt;      easier for the application writer, since there are many apps for</i><br>
<i>&gt;      every Source.</i><br>
<p>
We have a somewhat different paradigm here, as compared to the number of<br>
available applications that want to handle scanners directly, the number of<br>
supported source sis rather big. However if we had a very simple API,<br>
like TWAIN is supposed to be, this could change.<br>
<p>
<i>&gt; -    And having said that, let me say that TWAIN has been and is</i><br>
<i>&gt;      continuing to emphasize the programmatic side of the interface.</i><br>
<i>&gt;      This is because some application writers really hate those</i><br>
<i>&gt;       internal TWAIN GUIs, and want to assume full control of the</i><br>
<i>&gt;      Source.  It's an ongoing process to convince Source writers to</i><br>
<i>&gt;       take the time to fill out both interfaces.</i><br>
<p>
Yes. I see. Moving to a scheme like the one I propose above would very<br>
probably emphasize that need.<br>
<p>
The SANE API gives full control to the application programmer, while using<br>
some standard frontend we could also provide the simpler to use TWAIN API<br>
in one swoop.<br>
<p>
The SANE API enforces the complex, yet detailed interface between front- and<br>
backend. Using a frontend you can get a simple API from it, giving you both<br>
sides of the coin.<br>
<p>
<i>&gt; As I've stated in my other mail messages today, I believe the</i><br>
<i>&gt; immediate win from seeing SANE and TWAIN on UNIX, Windows</i><br>
<i>&gt; and Macintosh platforms is that it removes an impediment from</i><br>
<i>&gt; application writers who want to try their hand on another platform</i><br>
<i>&gt; without massive code rewrites.</i><br>
<p>
Yes. I think this is most easily possible by separting out everything in<br>
which the different host OSes differ. To me that is:<br>
<p>
- hardware interfacing (handled by the sanei_* interfaces)<br>
- GUI (handled by the SANE frontends)<br>
- eventually inter-process-communication (handled by the TWAIN_2_SANE bit<br>
  I mentioned earlier).<br>
<p>
<i>&gt; In the case of TWAIN that means that a Windowing system must</i><br>
<i>&gt; be present. </i><br>
<p>
Yes. <br>
<p>
<i>&gt;  And on UNIX that really points the finger at X-Windows.</i><br>
<p>
Yes, but please note, that there are other GUIs for Unix in existence.<br>
Berlin for example. Moreover, if we can separate out the GUI, this<br>
eases driver writing tremendously.<br>
<p>
<i>&gt; Of course, the cool thing about X is that it can display windows</i><br>
<i>&gt; across the net, so the fact that TWAIN requires a GUI does not</i><br>
<i>&gt; preclude the use of remote capture devices.</i><br>
<p>
Yes. But doing so is no fun, even on the common connection I'd expect, which<br>
is 10Mbit Ethernet, i.e. the common LAN. Also note, that this means you need<br>
a shell account on the remote system, and you need you application software<br>
(that makes the TWAIN-request) running on the host.<br>
<p>
<i>&gt; For the time being I recommend that we not worry about running</i><br>
<i>&gt; TWAIN on console mode systems.  TK/TCL could be used to</i><br>
<i>&gt; accomodate this, but if my initial assumption is true, that the first</i><br>
<i>&gt; targeted developer audience is application ports, then there</i><br>
<i>&gt; won't be anyone interested in running TWAIN on a system that</i><br>
<i>&gt; isn't also running X.</i><br>
<p>
Yes. For running console mode or doing stuff like a CGI Interface to the<br>
scanner (I have that running here for the Windows clients in the LAN), <br>
I suppose it would make sense to bypass the TWAIN layer and directly talk to<br>
SANE.<br>
<p>
<i>&gt; There is nothing preventing us from looking</i><br>
<i>&gt; into this later, if a real need is identified (I realize that some remote</i><br>
<i>&gt; scanning solutions might be 'very' interested in this).</i><br>
<p>
Actually the most interesting thing in that area would be scanners that<br>
directly export the SANE network API. Or - more interesting than scanners:<br>
WebCams.<br>
<p>
<i>&gt; As for the look of the different TWAIN GUIs...</i><br>
<i>&gt; It is ideal in that it allows a hardware vendor to present their </i><br>
<i>&gt; device the way they want (which presumably accesses all the features </i><br>
<i>&gt; of the device). </i><br>
<p>
Yes. This is still possible, and IMHO even simplified using the split driver<br>
model, as you can then implement the frontend and the backend independently<br>
and in parallel using existing components as counterpart.<br>
<p>
<i>&gt; We've discussed the notion of a single, standard interface that</i><br>
<i>&gt; applications could invoke as an alternative to the Source's GUI</i><br>
<i>&gt; and to writing a complete programmatic interface.  This path</i><br>
<i>&gt; looks nastier the longer one looks at it so we've shelved it for</i><br>
<i>&gt; now, but if the SANE group has ideas on this, we're more than</i><br>
<i>&gt; happy to dust off the issues and chat about them again...</i><br>
<p>
Yes. I think SANE is quite that. It basically solves that issue by seeing<br>
the device much like an electrical switchboard (which it more or less is<br>
from a theoretical point of view). Each control on that board has several<br>
possible states (like on/off, color/grey/lineart, 20-1200dpi, ...) and that<br>
states and the constraints imposed upon them are recorded in what we call<br>
option descriptors.<br>
<p>
Thus towards the GUI, we do not describe, how it should look like, but only<br>
what options it should offer and which possible values it can accept.<br>
<p>
The frontend then decides on how to render that information into a control<br>
panel. It will e.g. use sliders for continous controls, checkboxes for<br>
yes/no, radiobutton or dropdowns for one-out-of-many choices and the like.<br>
<p>
A custom GUI can of course just expect a certain set of options and map them<br>
arbitrarily, which allows to use the "stranger" controls some people like.<br>
<p>
<i>&gt; I realize that I may not have addressed all the items in your</i><br>
<i>&gt; message to me, but I also just noticed that I have to leave, so</i><br>
<i>&gt; I'm sending this out now.  Please let me know if I missed anything</i><br>
<i>&gt; that you want to discuss more...</i><br>
<p>
O.K. - I think this mail also got pretty long by now ... comments as always<br>
welcome.<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="0112.html">Petter Reinholdtsen: "Unexpected Win32 success story"</a>
<li> <b>Previous message:</b> <a href="0110.html">Andreas Beck: "Re: Starting a discussion about SANE and TWAIN..."</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>