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

<!-- received="Fri Aug 13 07:51:04 1999 PDT" -->
<!-- sent="Fri, 13 Aug 1999 16:56:53 +0200" -->
<!-- name="Andreas Beck" -->
<!-- email="becka@rz.uni-duesseldorf.de" -->
<!-- subject="Re: Starting a discussion about SANE and TWAIN..." -->
<!-- id="" -->
<!-- inreplyto="Pine.BSF.3.96.990812224739.81463B-100000@daphne.bogus" -->
<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>Fri, 13 Aug 1999 16:56:53 +0200</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#125">[ date ]</a><a href="index.html#125">[ thread ]</a><a href="subject.html#125">[ subject ]</a><a href="author.html#125">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0126.html">Andreas Beck: "Re: Starting a discussion about SANE and TWAIN..."</a>
<li> <b>Previous message:</b> <a href="0124.html">Lars Hanke: "Re: Starting a discussion about SANE and TWAIN..."</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>
<!-- body="start" -->
<i>&gt; Don't forget that linux runs on more then intel x86 hardware. </i><br>
<p>
Sure. Once you have the source in SANE style, compiling for another platform<br>
is simple. The problem with getting source will be, that many manufacturers<br>
will be pretty reluctant to give it out.<br>
<p>
While I personally doubt the commonly named reasons for this are really <br>
valid, I have to accept that, as the source is the writer's intellectual<br>
property, and he may decide what to do with it.<br>
<p>
But as said: If compiling the source on any platform is very easy, it gets<br>
more and more probable, that it will happen as well.<br>
<p>
We could even set up "trusted hosts" to compile the drivers on<br>
all known architectures automatically, when a manufacturer sends <br>
them there.<br>
<p>
<i>&gt; and should not be ignored.  Alpha (64 bits) and sparc (which is the other</i><br>
<i>&gt; endian if I remember right) present difficult problems if they are not</i><br>
<i>&gt; solved inheirantly in the design.</i><br>
<p>
Not really. Decently written software does not require much fuzzing around<br>
with endianness and data sizes.<br>
<p>
Note, that SANE seems to work well at least on Alpha, or David would <br>
probably not maintain it ;-).<br>
<p>
<i>&gt; &gt; Yes. Adding an ASPI layer for SANE should IMHO be no big deal. Generic SCSI</i><br>
<i>&gt; &gt; support is there for the Unixes in some flavours, so I assume adding in</i><br>
<i>&gt; &gt; ASPI shouldn't be a big deal.</i><br>
<p>
<i>&gt; Let me interrupt here and suggest Java.  Not nessicatly the programing</i><br>
<i>&gt; languge as Sun has defined it (though that has advantages), but something</i><br>
<i>&gt; with a simielar goal: a simple API/Programing language that can be used</i><br>
<i>&gt; to create a backend.  This will run on all platforms (ideally without the</i><br>
<i>&gt; endian issues that plague Sane today).</i><br>
<p>
I actually do not think, that interpreted bytecode is the greatest thing<br>
since sliced bread. O.K. - we are talking about scanners, that makes<br>
speed less of an issue usually, but I really do not think, we should waste<br>
lots of ressources interpreting bytecode, when all that is needed for<br>
getting a platform supported is ./configure;make;.<br>
<p>
I see your point about having instant support for every platform with that <br>
method, but I do not think it is practical. Just think about the development<br>
environments that would have to be written ....<br>
<p>
<i>&gt; internet.  Because the backend is platform independant there is no problem</i><br>
<i>&gt; with the manufacture not wanting to tell you how their scanner works, like</i><br>
<i>&gt; Sane faces today.  </i><br>
<p>
Not too right. We probably agree, that bytecode interpreted code would be<br>
required to get that level of portability. Now inside a modularized system<br>
like SANE, where drivers are relatively small and forced to communicate over<br>
predefined channels, reverse engineering becomes magnitudes easier.<br>
<p>
I have reverse engineered quite some software for various reasons, and the<br>
point is: The smaller the individual module, the better defined the<br>
interfaces and the higher level the development tools that were used in<br>
creating the thing, the easier it is to reverse engineer.<br>
<p>
<i>&gt; &gt; Most other methods (homebrew interface cards and such) aren't in common use</i><br>
<i>&gt; &gt; anymore these days.</i><br>
<i>&gt; Thank God...  Twane should probably expliciatly state that other</i><br>
<i>&gt; interfaces are not supported.  I'd consider dropping parallel ports and</i><br>
<i>&gt; serial ports in favor of Usb.  (this probably isn't pratical yet, but a</i><br>
<i>&gt; footnote to suggest moving to USB)  </i><br>
<p>
Note, that USB support in Unix is severly lacking.<br>
<p>
<i>&gt; I don't think Sane provides a network neighborhood type scanner brwoser,</i><br>
<i>&gt; but that would be a nice addition.</i><br>
<p>
No, it doesn't. It would be possible, though. The simplest way would be<br>
to autoprobe through the whole subnet. Other than that an announcement<br>
scheme would have to be invented.<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="0126.html">Andreas Beck: "Re: Starting a discussion about SANE and TWAIN..."</a>
<li> <b>Previous message:</b> <a href="0124.html">Lars Hanke: "Re: Starting a discussion about SANE and TWAIN..."</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>