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

<!-- received="Tue Aug 17 16:58:44 1999 PDT" -->
<!-- sent="Wed, 18 Aug 1999 01:34:41 +0200" -->
<!-- name="Andreas Beck" -->
<!-- email="becka@rz.uni-duesseldorf.de" -->
<!-- subject="Re: SANE V2" -->
<!-- id="" -->
<!-- inreplyto="199908161547.IAA08554@icarus.com" -->
<title>sane-devel: Re: SANE V2</title>
<h1>Re: SANE V2</h1>
<b>Andreas Beck</b> (<a href="mailto:becka@rz.uni-duesseldorf.de"><i>becka@rz.uni-duesseldorf.de</i></a>)<br>
<i>Wed, 18 Aug 1999 01:34:41 +0200</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#218">[ date ]</a><a href="index.html#218">[ thread ]</a><a href="subject.html#218">[ subject ]</a><a href="author.html#218">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0219.html">Andreas Beck: "Re: 2 scanners under Linux"</a>
<li> <b>Previous message:</b> <a href="0217.html">Bernd Schroeder: "Re: microtek X6 advance and TMA"</a>
<li> <b>In reply to:</b> <a href="0195.html">Stephen Williams: "Re: SANE V2"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>
<!-- body="start" -->
<i>&gt; &gt; O.K. - if it really really really pleases all people here, we can add</i><br>
<i>&gt; &gt; that  types. But as said, I am afraid of opening a neverending growth</i><br>
<i>&gt; &gt; of the frame types, which is very bad regarding compatibility and</i><br>
<i>&gt; &gt; cannot be easily  extended by just editing a textfile or something.</i><br>
<p>
<i>&gt; I made a proposal to handle compatibility, to wit:</i><br>
<p>
Not really. The point is, that o.k., you can have any old frontend work with<br>
any new driver by falling back to raw transfer mode, i.e. requiring support<br>
for one of the now existing formats.<br>
<p>
But this does not cover two important points:<br>
<p>
1. Medium-Old frontends that do not know format xxx together with a driver<br>
that does. Those frontends cannot do anything reasonable with the data <br>
the driver offers in format xxx. <br>
<p>
If the data can be transferred as raw data, this ensures interoperability,<br>
but you can't use the format xxx the source has at all, which might have<br>
advantages. And there are the cases, where the data is non-image for<br>
example, and thus can't be transferred as raw anyway. <br>
<p>
Yes - the frontend can save it blindly (which is the usual thing you want <br>
to do to non-raw data anyway), but it cannot tell the user what it will <br>
be saving, so he can decide whether it is worth the bother and eventually <br>
what program he will have to invoke later to somehow display or otherwise <br>
make sense of the data.<br>
<p>
Using the mime type (or any other standardized descriptive text) together<br>
with a single frametype has a big advantage: The "wit" to know what<br>
a frametype actually contains is completely inside the backend.<br>
<p>
No frontend, even an outdated one, needs to know the type to be able to<br>
present it to the user in a human-readable way.<br>
<p>
This is just like the options work: Their names show the _user_ what they<br>
mean. The frontend has no idea about that (execpt for the well-known ones,<br>
where the frontend can optionally be smart about them).<br>
<p>
The very same mechanism goes for the frametype. If it is something the<br>
frontend knows and can be smart about - fine. If not, it can forward<br>
the "brainwork" to the user. But for that it needs something the user<br>
can make sense of. It needs something like "image/jpeg" and not <br>
"Frametype 45". It would be just like if we numbered our options<br>
and told the frontends to keep up with the descriptions, if we <br>
just added frametypes.<br>
<p>
2. The last described problem could be handled by updating a mapping list<br>
that is used by the frontend, when types are added.<br>
<p>
However this requires a centralized control instance that gives out frame<br>
types and takes care to update the database and some reasoning within the<br>
backend distributions (which I assume to become decentralized, once<br>
manufacurers pick up on SANE) to make sure only the most recent, and only<br>
complete mapping lists are distributed.<br>
<p>
I do think, that centralized control over often-changing stuff should be<br>
avoided. It adds unnecessary buerocracy.<br>
<p>
Moreover - either we keep tight control over what frametypes will be allowed<br>
in and thus keep the database size at bay (thus disguesting some users<br>
that want to do the stranger stuff), or it will quickly blow up to a size, <br>
where we have reinvented mime.<br>
<p>
<i>&gt; ** Once the well-known format option is added, new "advanced" frame formats</i><br>
<i>&gt; ** can be added liberally without ever again breaking compatibility.</i><br>
<p>
Note, that the format might change within a series of frames from one<br>
sane_start(). Typical situation would be the batch scanning discussed<br>
recently. A well known option can be used to preselect a given format,<br>
but hardware contrains may e.g. demand to transmit the page thumbnail<br>
uncompressed, and rest compressed.<br>
<p>
This also applies to trying to handle barcodes in options. There could be<br>
multiple barcodes interspersed with image data.<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="0219.html">Andreas Beck: "Re: 2 scanners under Linux"</a>
<li> <b>Previous message:</b> <a href="0217.html">Bernd Schroeder: "Re: microtek X6 advance and TMA"</a>
<li> <b>In reply to:</b> <a href="0195.html">Stephen Williams: "Re: SANE V2"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>