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

<!-- received="Sat Aug 14 03:00:15 1999 PDT" -->
<!-- sent="Sat, 14 Aug 1999 12:03:21 +0200" -->
<!-- name="Andreas Beck" -->
<!-- email="becka@rz.uni-duesseldorf.de" -->
<!-- subject="Re: Starting a discussion about SANE and TWAIN..." -->
<!-- id="" -->
<!-- inreplyto="37B491C7.F9F6E1F2@wolfsburg.de" -->
<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>Sat, 14 Aug 1999 12:03:21 +0200</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#138">[ date ]</a><a href="index.html#138">[ thread ]</a><a href="subject.html#138">[ subject ]</a><a href="author.html#138">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0139.html">Benedikt Eric Heinen: "Coolscan-III (vertical vs horizontal position of scanner)?"</a>
<li> <b>Previous message:</b> <a href="0137.html">Henry Miller: "Re: Starting a discussion about SANE and TWAIN..."</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>
<!-- body="start" -->
<i>&gt; &gt; SANE interfacing. To do it "right", we will need to define a "remote</i><br>
<i>&gt; &gt; control API" for each architecture we want to run on, which will allow</i><br>
<i>&gt; &gt; the TWAIN layer to interface with an arbitrary SANE frontend.</i><br>
<p>
<i>&gt; I am interested in adding a TWAIN-driver-level-interface to xsane.</i><br>
<p>
Good. And you are the perfect person to try it first, as you're the author<br>
of xsane and have a very thorough understanding of SANE.<br>
Yes. I think we should try exactly this. When we have it running with<br>
xsane, we can add the interface to other frontends as need arises.<br>
<p>
<i>&gt; &gt; abovementioned "remote control" for SANE frontends.</i><br>
<p>
<i>&gt; We should define a standard for the communication</i><br>
<i>&gt; between the TWAIN to SANE-FRONTEND wrapper</i><br>
<i>&gt; and sane frontends.</i><br>
<p>
Yes. Let's give this a try:<br>
<p>
<i>&gt; -- TWAIN-application layer</i><br>
<p>
I think this is well defined by the TWAIN standard. AFAIK all that needs to<br>
be done is to (dynamically) link the application to a TWAIN library and<br>
calling into it - right ? Mark ?<br>
<p>
<i>&gt; -&gt; TWAIN-source-selection-layer</i><br>
<p>
I am a little unsure here: Should we map that right through to the SANE<br>
source selection, or rather leave that to the SANE frontend's GUI itself <br>
and use the source selection of TWAIN to select the SANE frontend ?<br>
<p>
The best thing would probably be to go through a configuration file that<br>
looks a bit like that:<br>
<p>
# TWAIN_2_SANE bridge configuration<br>
#<br>
# Available sources:<br>
#<br>
# Show all devices that xsane sees<br>
xsane:*<br>
# Show only a single device for the vendor-GUI, which only works right<br>
# with the vendor4711 scanner anyway:<br>
vendorGUI:vendor4711<br>
<p>
We could as well add in sections that select by the asking program, thus<br>
e.g. giving the GUI that fits best with the look and feel of the requesting<br>
program.<br>
<p>
Other than that, I'd say we just implement that as part of the TWAIN library<br>
that gets linked to the application. <br>
<p>
<i>&gt; -&gt; TWAIN to  SANE-FRONTEND-wrapper</i><br>
<p>
That is the hard part, especially, if we try to:<br>
<p>
<i>&gt; The wrapper and the standard has to be compatible to</i><br>
<i>&gt; all operating systems.</i><br>
<p>
On Unix I would use some form of IPC. Probably pipes. How is it handled on<br>
Win and MacOS now ?<br>
<p>
I.e. is the scanner GUI run as dynamically linked "subroutine" of the main<br>
program or is a separate program started to display the GUI and communicate<br>
with the TWAIN library ?<br>
<p>
Using the cygwin tools, it should be definitely possible to use the separate<br>
program+IPC approach on windows, but I do not know about the Mac.<br>
<p>
The advantages of the separate process approach are:<br>
<p>
- The SANE frontends need only minimal modification, and they still run<br>
  standalone.<br>
- The frontend and backend can use separate GUI-toolkits without pushing<br>
  the memory requirements for the main application up further. Total memory<br>
  requirement is the same of course, but often application memory space is<br>
  limited on a per application basis.<br>
- Security is enhanced, as the frontends run in a separate memory space.<br>
  This means:<br>
a) a faulty frontend cannot take down the application. I have seen too many<br>
   badly written GUI-frontends from vendors that could be taken down by<br>
   pressing the wrong combination of options. I think most users would<br>
   be grateful, if the graphics program with the many unsaved changes would<br>
   continue running, even if the frontend crashed.<br>
b) the frontend can be given extra permissions like being "sgid-scanner"<br>
   giving it access to the SCSI devices. I know, that security is not much of<br>
   an issue on the average Win box, but for Unix, you will not get a foot on<br>
   the ground, if security is not maintained.<br>
<p>
The disadvantage is having to use IPC instead of direct procedure calls.<br>
And IPC is strongly system dependent. I think no system would have a problem<br>
with spawning an extra process, as this is a common thing used for calling<br>
up a help browser or similar. So the question is about IPC.<br>
<p>
As long as we have a posixish environment, we should have pipes, which<br>
should suffice for that task. <br>
<p>
But actually, as both the TWAIN library and the frontends will depend on the<br>
Host OS (the former due to the way they need to be linked, which is a minor<br>
issue, but the latter due to the GUI), this is not so big an issue, as we<br>
can define an ideal method of communications for each platform separately.<br>
The more we can unify, the better, though.<br>
<p>
I think pipes are probably best for starters, as they enforce a streamed<br>
protocol, that can definitely be used on any platform of interest, at worst<br>
using a TCP/IP connection to localhost, which every platform that is in use<br>
nowadays should support.<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="0139.html">Benedikt Eric Heinen: "Coolscan-III (vertical vs horizontal position of scanner)?"</a>
<li> <b>Previous message:</b> <a href="0137.html">Henry Miller: "Re: Starting a discussion about SANE and TWAIN..."</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>