kopia lustrzana https://gitlab.com/sane-project/website
149 wiersze
6.8 KiB
HTML
149 wiersze
6.8 KiB
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>> > SANE interfacing. To do it "right", we will need to define a "remote</i><br>
|
|||
|
<i>> > control API" for each architecture we want to run on, which will allow</i><br>
|
|||
|
<i>> > the TWAIN layer to interface with an arbitrary SANE frontend.</i><br>
|
|||
|
<p>
|
|||
|
<i>> 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>> > abovementioned "remote control" for SANE frontends.</i><br>
|
|||
|
<p>
|
|||
|
<i>> We should define a standard for the communication</i><br>
|
|||
|
<i>> between the TWAIN to SANE-FRONTEND wrapper</i><br>
|
|||
|
<i>> and sane frontends.</i><br>
|
|||
|
<p>
|
|||
|
Yes. Let's give this a try:<br>
|
|||
|
<p>
|
|||
|
<i>> -- 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>> -> 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>> -> TWAIN to SANE-FRONTEND-wrapper</i><br>
|
|||
|
<p>
|
|||
|
That is the hard part, especially, if we try to:<br>
|
|||
|
<p>
|
|||
|
<i>> The wrapper and the standard has to be compatible to</i><br>
|
|||
|
<i>> 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 : <<a href="mailto:andreas.beck@ggi-project.org">andreas.beck@ggi-project.org</a>> =
|
|||
|
<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>
|