kopia lustrzana https://gitlab.com/sane-project/website
304 wiersze
16 KiB
HTML
304 wiersze
16 KiB
HTML
|
<!-- received="Thu Aug 12 21:27:42 1999 PDT" -->
|
|||
|
|
<!-- sent="Thu, 12 Aug 1999 23:27:04 -0500 (CDT)" -->
|
|||
|
|
<!-- name="Henry Miller" -->
|
|||
|
|
<!-- email="hank@black-hole.com" -->
|
|||
|
|
<!-- subject="Re: Starting a discussion about SANE and TWAIN..." -->
|
|||
|
|
<!-- id="" -->
|
|||
|
|
<!-- inreplyto="19990812205552.C799@rz.uni-duesseldorf.de" -->
|
|||
|
|
<title>sane-devel: Re: Starting a discussion about SANE and TWAIN...</title>
|
|||
|
|
<h1>Re: Starting a discussion about SANE and TWAIN...</h1>
|
|||
|
|
<b>Henry Miller</b> (<a href="mailto:hank@black-hole.com"><i>hank@black-hole.com</i></a>)<br>
|
|||
|
|
<i>Thu, 12 Aug 1999 23:27:04 -0500 (CDT)</i>
|
|||
|
|
<p>
|
|||
|
|
<ul>
|
|||
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#115">[ date ]</a><a href="index.html#115">[ thread ]</a><a href="subject.html#115">[ subject ]</a><a href="author.html#115">[ author ]</a>
|
|||
|
|
<!-- next="start" -->
|
|||
|
|
<li> <b>Next message:</b> <a href="0116.html">Peter Aksberg: "SV: modprobe"</a>
|
|||
|
|
<li> <b>Previous message:</b> <a href="0114.html">Andreas Beck: "Re: Unexpected Win32 success story"</a>
|
|||
|
|
<!-- nextthread="start" -->
|
|||
|
|
<!-- reply="end" -->
|
|||
|
|
</ul>
|
|||
|
|
<!-- body="start" -->
|
|||
|
|
Don't forget that linux runs on more then intel x86 hardware. PPC,<br>
|
|||
|
|
m68000 (not just macs), ARM, alpha, sparc, and Mips all come to mind as<br>
|
|||
|
|
platforms that linux users want support for. There are a number of people<br>
|
|||
|
|
using Linux on x86 who can esailly be presuaded not to use a program<br>
|
|||
|
|
because it doens't run on non-x86 computers. These are real world users,<br>
|
|||
|
|
and should not be ignored. Alpha (64 bits) and sparc (which is the other<br>
|
|||
|
|
endian if I remember right) present difficult problems if they are not<br>
|
|||
|
|
solved inheirantly in the design.<br>
|
|||
|
|
<p>
|
|||
|
|
On Thu, 12 Aug 1999, Andreas Beck wrote:<br>
|
|||
|
|
<p>
|
|||
|
|
<i>> > Your comment about abstaction layers is of keen interest to</i><br>
|
|||
|
|
<i>> > me. I'm not just interested in seeing TWAIN on UNIX. I think</i><br>
|
|||
|
|
<i>> > there is an opportunity with SANE to create a driver development</i><br>
|
|||
|
|
<i>> > 'kit' that abstracts away the physical communication with the OS,</i><br>
|
|||
|
|
<i>> > rather like ASPI does, though I'd like to see something less wire</i><br>
|
|||
|
|
<i>> > dependent.</i><br>
|
|||
|
|
<i>> > </i><br>
|
|||
|
|
<i>> > Perhaps such an abstraction already exists, if not it needs to,</i><br>
|
|||
|
|
<i>> > since it would significantly reduce the effort of porting drivers from</i><br>
|
|||
|
|
<i>> > one OS to another, which is the main reason you see so many</i><br>
|
|||
|
|
<i>> > devices well supported on one platform and weakly supported</i><br>
|
|||
|
|
<i>> > or unsupported on others.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> Yes. This is exectly, why sane includes the sanei_* interfacing files that</i><br>
|
|||
|
|
<i>> abstract the paths to the hardware.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> > In this case it would then be highly desireable to see SANE</i><br>
|
|||
|
|
<i>> > on Macintosh and Windows platforms, since it would reduce</i><br>
|
|||
|
|
<i>> > the driver development effort.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> Yes. Adding an ASPI layer for SANE should IMHO be no big deal. Generic SCSI</i><br>
|
|||
|
|
<i>> support is there for the Unixes in some flavours, so I assume adding in</i><br>
|
|||
|
|
<i>> ASPI shouldn't be a big deal.</i><br>
|
|||
|
|
<p>
|
|||
|
|
Let me interrupt here and suggest Java. Not nessicatly the programing<br>
|
|||
|
|
languge as Sun has defined it (though that has advantages), but something<br>
|
|||
|
|
with a simielar goal: a simple API/Programing language that can be used<br>
|
|||
|
|
to create a backend. This will run on all platforms (ideally without the<br>
|
|||
|
|
endian issues that plague Sane today).<br>
|
|||
|
|
<p>
|
|||
|
|
Now a manufacture only needs to provide this driver, everything else is<br>
|
|||
|
|
(presumiably, I know that MacSane and WinSane are not stable if they<br>
|
|||
|
|
exist at all) already in Sane. Thats not to say that Sane is perfect as<br>
|
|||
|
|
it is, only that a frontend is likely to be written. For this reasons I'm<br>
|
|||
|
|
going to use Twane as the combination of twain and sane in what follows,<br>
|
|||
|
|
to indicate that even though this is like Sane, it is extended, and might<br>
|
|||
|
|
or might not be compateable with Sane.<br>
|
|||
|
|
<p>
|
|||
|
|
Lets look at your typical manufacture: they do reasearch and decide that<br>
|
|||
|
|
85% (I made this number up, but it is reasonable) of their cusotmers will<br>
|
|||
|
|
run windows 98. So they write the backend, once, and distribtue that.<br>
|
|||
|
|
They also buy the rights to winSane, put their own logo on it, and change<br>
|
|||
|
|
some of the buttons so they look better with their scanner's features.<br>
|
|||
|
|
<p>
|
|||
|
|
Everything else is included already, if you want network scanning, that<br>
|
|||
|
|
comes free. They basicly package the rest of Twane on a CD rom, with no<br>
|
|||
|
|
programing effort.<br>
|
|||
|
|
<p>
|
|||
|
|
Now for the other cusotmers, they take the backend (which is<br>
|
|||
|
|
platform independant, so it will run on the new intel CPU that isn't<br>
|
|||
|
|
released yet) and download the Twane package for their computer from the<br>
|
|||
|
|
internet. Because the backend is platform independant there is no problem<br>
|
|||
|
|
with the manufacture not wanting to tell you how their scanner works, like<br>
|
|||
|
|
Sane faces today. <br>
|
|||
|
|
<p>
|
|||
|
|
<i>> I see more problems on the common "ad-hoc" interfaces that were</i><br>
|
|||
|
|
<i>> invented, like using the parallel port, or the serial port in</i><br>
|
|||
|
|
<i>> nonstandard ways. I have heard of at least one scanner that uses the</i><br>
|
|||
|
|
<i>> serial port modem control lines instead of the data lines to transmit</i><br>
|
|||
|
|
<i>> data. </i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> We should make up standard APIs for accessing:</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> - the SCSI-buses of the host system</i><br>
|
|||
|
|
<i>> - serial ports (used in the "normal" way).</i><br>
|
|||
|
|
<i>> - parallel ports</i><br>
|
|||
|
|
<i>> - USB</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> Most other methods (homebrew interface cards and such) aren't in common use</i><br>
|
|||
|
|
<i>> anymore these days.</i><br>
|
|||
|
|
<p>
|
|||
|
|
Thank God... Twane should probably expliciatly state that other<br>
|
|||
|
|
interfaces are not supported. I'd consider dropping parallel ports and<br>
|
|||
|
|
serial ports in favor of Usb. (this probably isn't pratical yet, but a<br>
|
|||
|
|
footnote to suggest moving to USB) <br>
|
|||
|
|
<p>
|
|||
|
|
This make Twane responsiable for defining other interfaces as needed. For<br>
|
|||
|
|
instance if some want a firewire interface, or fibre channel. (accually<br>
|
|||
|
|
the above two are scsi so this is a bad example, but I can't think of<br>
|
|||
|
|
anything else offhand. Maybe the apple desktop bus but that is obsolete<br>
|
|||
|
|
in Apple's eyes)<br>
|
|||
|
|
<p>
|
|||
|
|
<i>> Yes and no. SANE does have GUIs (two of the three existing SANE frontends</i><br>
|
|||
|
|
<i>> are graphical), but the GUI is not tied to the scanner.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> It is possible to write customized GUIs that work with only one scanner</i><br>
|
|||
|
|
<i>> and can be tweaked to the manufacturer's liking.</i><br>
|
|||
|
|
<p>
|
|||
|
|
Right, and this is a strenght. We provide a reference implimentation, I<br>
|
|||
|
|
suspect that the rights to windows frontend could be bought, and all a<br>
|
|||
|
|
manufacture would do it put their logo on it, and a few other changes.<br>
|
|||
|
|
This goes a long way toward your goal of making it easier for the<br>
|
|||
|
|
programers. The GUI is the hardest part of writing a program like this,<br>
|
|||
|
|
and they can do nothing if they are willing for a reference<br>
|
|||
|
|
implimentation.<br>
|
|||
|
|
<p>
|
|||
|
|
<i>> > - TWAIN assumes the presence of a Windowing system (which</i><br>
|
|||
|
|
<i>> > is pretty reasonable for Windows and Macintosh, and for a</i><br>
|
|||
|
|
<i>> > lot of UNIX systems). The reason for the GUI is that it takes</i><br>
|
|||
|
|
<i>> > away the burden of capability negotiation from the application</i><br>
|
|||
|
|
<i>> > writer. </i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> Yes. This is what we should add to SANE in a generic manner. The existing</i><br>
|
|||
|
|
<i>> frontends are capable of interfacing with the most well known photo-retuche</i><br>
|
|||
|
|
<i>> software for Unix, the GIMP, but not much else.</i><br>
|
|||
|
|
(snip)<br>
|
|||
|
|
<i>> So it would look like this:</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> application -> TWAIN-API -> TWAIN_2_SANE frontend remote control interface</i><br>
|
|||
|
|
<i>> -> SANE frontend -> SANE backend.</i><br>
|
|||
|
|
<i>></i><br>
|
|||
|
|
<i>> This gives the best of both worlds:</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> The application uses the simple but small and efficient TWAIN API, which is</i><br>
|
|||
|
|
<i>> well known and thus no problem to implement for most programmers.</i><br>
|
|||
|
|
<p>
|
|||
|
|
Good idea. Worth repeating.<br>
|
|||
|
|
<p>
|
|||
|
|
<i>> We write a TWAIN_2_SANE glue layer, that handles communication with the</i><br>
|
|||
|
|
<i>> SANE frontend, which display the GUI, lets the user press his buttons and</i><br>
|
|||
|
|
<i>> hands back image data to the application.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> The sane frontend communicates with its backend as usual.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> > This means that an app writer can communicate with a</i><br>
|
|||
|
|
<i>> > Source with a minimum number of calls, without losing access</i><br>
|
|||
|
|
<i>> > to all the features of the device represented by the Source.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> Yes. However, tying the GUI into the driver itself means, that you have to</i><br>
|
|||
|
|
<i>> heavily modify the driver for each GUI. GUIs differ very much in their</i><br>
|
|||
|
|
<i>> method of communicating with their client programs, what often requires </i><br>
|
|||
|
|
<i>> large source code changes to accomdate different programming methods that</i><br>
|
|||
|
|
<i>> are to be preferred for the different GUIs.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> This is why I suggest that extra layer. The GUI gets insulated in the</i><br>
|
|||
|
|
<i>> SANE frontend.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> This allows to - for starters - write one single X11 GUI and be done with</i><br>
|
|||
|
|
<i>> it. All the manufacturer really needs to deliver is the backend.</i><br>
|
|||
|
|
<p>
|
|||
|
|
Right, no need for front ends, but you can get as complex as your<br>
|
|||
|
|
like/money allows.<br>
|
|||
|
|
<br>
|
|||
|
|
<i>> The application->TWAIN->frontend patch can be done with standard</i><br>
|
|||
|
|
<i>> components.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> > - I'm going to say that last bit again in a different way, since it is</i><br>
|
|||
|
|
<i>> > an important part of the TWAIN philosophy. When we are</i><br>
|
|||
|
|
<i>> > working on the TWAIN specification, we often ask the question</i><br>
|
|||
|
|
<i>> > "does this make things easier for the Source writer or for the</i><br>
|
|||
|
|
<i>> > application writer?" Whenever possible we try to make things</i><br>
|
|||
|
|
<i>> > easier for the application writer, since there are many apps for</i><br>
|
|||
|
|
<i>> > every Source.</i><br>
|
|||
|
|
<p>
|
|||
|
|
Yes, but by adding Sane in (or forcing all Twain programers to impliment<br>
|
|||
|
|
this part of Twain) the application programer can be lazy if they want, or<br>
|
|||
|
|
they can go through as much effort as they want. The first programers<br>
|
|||
|
|
working with a new 3-D screen would want to be elaberate in their killer<br>
|
|||
|
|
application. <br>
|
|||
|
|
<p>
|
|||
|
|
<i>> We have a somewhat different paradigm here, as compared to the number of</i><br>
|
|||
|
|
<i>> available applications that want to handle scanners directly, the number of</i><br>
|
|||
|
|
<i>> supported source sis rather big. However if we had a very simple API,</i><br>
|
|||
|
|
<i>> like TWAIN is supposed to be, this could change.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> > - And having said that, let me say that TWAIN has been and is</i><br>
|
|||
|
|
<i>> > continuing to emphasize the programmatic side of the interface.</i><br>
|
|||
|
|
<i>> > This is because some application writers really hate those</i><br>
|
|||
|
|
<i>> > internal TWAIN GUIs, and want to assume full control of the</i><br>
|
|||
|
|
<i>> > Source. It's an ongoing process to convince Source writers to</i><br>
|
|||
|
|
<i>> > take the time to fill out both interfaces.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> Yes. I see. Moving to a scheme like the one I propose above would very</i><br>
|
|||
|
|
<i>> probably emphasize that need.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> The SANE API gives full control to the application programmer, while using</i><br>
|
|||
|
|
<i>> some standard frontend we could also provide the simpler to use TWAIN API</i><br>
|
|||
|
|
<i>> in one swoop.</i><br>
|
|||
|
|
<p>
|
|||
|
|
Which is really the have your cake and eat it too that we want.<br>
|
|||
|
|
<p>
|
|||
|
|
<i>> The SANE API enforces the complex, yet detailed interface between front- and</i><br>
|
|||
|
|
<i>> backend. Using a frontend you can get a simple API from it, giving you both</i><br>
|
|||
|
|
<i>> sides of the coin.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> > As I've stated in my other mail messages today, I believe the</i><br>
|
|||
|
|
<i>> > immediate win from seeing SANE and TWAIN on UNIX, Windows</i><br>
|
|||
|
|
<i>> > and Macintosh platforms is that it removes an impediment from</i><br>
|
|||
|
|
<i>> > application writers who want to try their hand on another platform</i><br>
|
|||
|
|
<i>> > without massive code rewrites.</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> Yes. I think this is most easily possible by separting out everything in</i><br>
|
|||
|
|
<i>> which the different host OSes differ. To me that is:</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> - hardware interfacing (handled by the sanei_* interfaces)</i><br>
|
|||
|
|
<i>> - GUI (handled by the SANE frontends)</i><br>
|
|||
|
|
<i>> - eventually inter-process-communication (handled by the TWAIN_2_SANE bit</i><br>
|
|||
|
|
<i>> I mentioned earlier).</i><br>
|
|||
|
|
<i>> </i><br>
|
|||
|
|
<i>> > Of course, the cool thing about X is that it can display windows</i><br>
|
|||
|
|
<i>> > across the net, so the fact that TWAIN requires a GUI does not</i><br>
|
|||
|
|
<i>> > preclude the use of remote capture devices.</i><br>
|
|||
|
|
<p>
|
|||
|
|
This works, but isn't the right way to do things. It is easier to have<br>
|
|||
|
|
Twane discover all scanners on the network from whatever machine it is<br>
|
|||
|
|
started from than log into the machine the scanner is attached to, and set<br>
|
|||
|
|
your display back. Not that it is impossibal, only that it isn't as<br>
|
|||
|
|
transparent as we would like. <br>
|
|||
|
|
<p>
|
|||
|
|
I don't think Sane provides a network neighborhood type scanner brwoser,<br>
|
|||
|
|
but that would be a nice addition.<br>
|
|||
|
|
<p>
|
|||
|
|
<i>> > For the time being I recommend that we not worry about running</i><br>
|
|||
|
|
<i>> > TWAIN on console mode systems. TK/TCL could be used to</i><br>
|
|||
|
|
<i>> > accomodate this, but if my initial assumption is true, that the first</i><br>
|
|||
|
|
<i>> > targeted developer audience is application ports, then there</i><br>
|
|||
|
|
<i>> > won't be anyone interested in running TWAIN on a system that</i><br>
|
|||
|
|
<i>> > isn't also running X.</i><br>
|
|||
|
|
<p>
|
|||
|
|
Don't belive that. Unix is used for a lot more automatic work. Consider<br>
|
|||
|
|
an automatic document feeder. The user of such a thing may want to dump<br>
|
|||
|
|
20,000 checks into the machine and after finishing lunch see the numerbs<br>
|
|||
|
|
in the spreadsheets This is the ideal application for not using a gui.<br>
|
|||
|
|
(Checks are simple forms, and if you can write a working OCR [not easy]<br>
|
|||
|
|
you can batch process them) Why have a gui when the user won't even look<br>
|
|||
|
|
at it? <br>
|
|||
|
|
<p>
|
|||
|
|
<i>> > There is nothing preventing us from looking</i><br>
|
|||
|
|
<i>> > into this later, if a real need is identified (I realize that some remote</i><br>
|
|||
|
|
<i>> > scanning solutions might be 'very' interested in this).</i><br>
|
|||
|
|
<p>
|
|||
|
|
Expirence with Twain seems to have taught that the optional featuers are<br>
|
|||
|
|
not implimentated. Twain does provide a way for an application to address<br>
|
|||
|
|
a scanner directly, but it isn't used in most scanners.<br>
|
|||
|
|
<p>
|
|||
|
|
<i>> > We've discussed the notion of a single, standard interface that</i><br>
|
|||
|
|
<i>> > applications could invoke as an alternative to the Source's GUI</i><br>
|
|||
|
|
<i>> > and to writing a complete programmatic interface. This path</i><br>
|
|||
|
|
<i>> > looks nastier the longer one looks at it so we've shelved it for</i><br>
|
|||
|
|
<i>> > now, but if the SANE group has ideas on this, we're more than</i><br>
|
|||
|
|
<i>> > happy to dust off the issues and chat about them again...</i><br>
|
|||
|
|
<p>
|
|||
|
|
I'm not sure why Sane hasn't solved this, when you remember that a<br>
|
|||
|
|
manufactures can customise their GUIs.<br>
|
|||
|
|
<p>
|
|||
|
|
<i>> Thus towards the GUI, we do not describe, how it should look like, but only</i><br>
|
|||
|
|
<i>> what options it should offer and which possible values it can accept.</i><br>
|
|||
|
|
<p>
|
|||
|
|
<p>
|
|||
|
|
<p>
|
|||
|
|
<pre>
|
|||
|
|
--
|
|||
|
|
<a href="http://www.black-hole.com/users/henrymiller/">http://www.black-hole.com/users/henrymiller/</a>
|
|||
|
|
<a href="mailto:hank@black-hole.com">hank@black-hole.com</a>
|
|||
|
|
<p>
|
|||
|
|
<p>
|
|||
|
|
<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="0116.html">Peter Aksberg: "SV: modprobe"</a>
|
|||
|
|
<li> <b>Previous message:</b> <a href="0114.html">Andreas Beck: "Re: Unexpected Win32 success story"</a>
|
|||
|
|
<!-- nextthread="start" -->
|
|||
|
|
<!-- reply="end" -->
|
|||
|
|
</ul>
|