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

<!-- received="Mon Aug 23 09:11:22 1999 PDT" -->
<!-- sent="Mon, 23 Aug 1999 09:36:15 +0200" -->
<!-- name="Andreas Beck" -->
<!-- email="becka@rz.uni-duesseldorf.de" -->
<!-- subject="Re: SANE V2" -->
<!-- id="" -->
<!-- inreplyto="Pine.LNX.4.10.9908230040420.11430-100000@chef.ecs.soton.ac.uk" -->
<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>Mon, 23 Aug 1999 09:36:15 +0200</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#282">[ date ]</a><a href="index.html#282">[ thread ]</a><a href="subject.html#282">[ subject ]</a><a href="author.html#282">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0283.html">Cooper: "Re: Machine lock-ups while scanning. HP scanjet 5P/BusLogic Flashpoint"</a>
<li> <b>Previous message:</b> <a href="0281.html">Oliver Rauch: "Re: UMAX parallel port scanner"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>
<!-- body="start" -->
<i>&gt; Well, Andreas seems primarily to be concerned about indentifying a frame</i><br>
<i>&gt; type to the user in the event that it's not natively understand by an</i><br>
<i>&gt; old backend. </i><br>
<p>
No. I am concerned about being able to upgrade a frontend without<br>
even recompiling. Enums are very bad to do this. Yes. One can make <br>
a mapping database that maps the numeric values, but that's not terribly<br>
descriptive or readable afterwards, and thus not maintainer friendly.<br>
<p>
Binary compatibility is something very important to mainstream software<br>
that has many many contributors, and even eventually commercial contributors<br>
in future.<br>
<p>
Enums just do not work out on that. I've been through this on several<br>
projects. The constant upgrading of the .h files only ended when we went to<br>
much more general description schemes. And those projects had smaller scope<br>
to describe in the enum than image formats.<br>
<p>
<i>&gt; We can simply associate a short text string with each defined type, in</i><br>
<i>&gt; the standard and in backend header files, and any frontend which can't</i><br>
<i>&gt; handle the data format it receives (presumably because of a user</i><br>
<i>&gt; advanced setting or badly behaved backend) will just look in the</i><br>
<i>&gt; getparm results for "frame_description" and say...</i><br>
<i>&gt; </i><br>
<i>&gt; Sorry, I can't handle image data in the format:</i><br>
<i>&gt; &lt;insert short description here&gt;</i><br>
<i>&gt; Save to a file anyway? (Y)es / No</i><br>
<p>
So we double-transfer the datatype ?<br>
<p>
And miss the opportunity to be able to ask without further configuration:<br>
Save, Open using 'program xxx', or ignore frame ?<br>
<p>
<i>&gt; The other point which _keeps_ being made by proponents of MIME in this</i><br>
<i>&gt; debate is that there will "inevitably" be a huge number of formats to</i><br>
<i>&gt; support </i><br>
<p>
I have seen the proposals up to now. Already too much for my taste.<br>
<p>
<i>&gt; -- yet this is hardly bourne out by an examination of MIME</i><br>
<p>
I have read RFC 1341, 1521 and 1522. And I suggest you should do so, too,<br>
before judging about the preciseness, the possibility of transferring<br>
outband data or whatever on MIME.<br>
<p>
I simply hate doing double work, and using that "short description" you<br>
propose is exactly that. You seem to be concerned about having precisely<br>
defined standards for each image type. O.K. - where is the problem ?<br>
Do you think we can do better than the IANA ?<br>
<p>
The MIME RFC specifies, that new types need to be passed by IANA and need to<br>
point to an open specification of the content that is in an RFC or proposed <br>
RFC.<br>
<p>
Heck - they do all the work for us. Why waste it and set our own monument ?<br>
<p>
<i>&gt; or by looking at scanners "In the wild". The four new data formats</i><br>
<i>&gt; (and two other formats) suggested by backend writers so far seem to</i><br>
<i>&gt; cover a broad range of high-end scanners.</i><br>
<p>
Even that silly RGBI frame stuff is very inappropriate. The "I" is highly<br>
unspecific.<br>
<p>
The notion of using an Infrared channel as an alpha channel is highly<br>
specific to the dust-reduction method using _transmitted_ IR. Reflected or<br>
emitted IR like cameras deliver (and yes, I had such devices in my very <br>
hands) are a completely different piece of cake.<br>
<p>
Using the system I favour, this is a matter of a very simple configuration<br>
file that will just map a transmitted IR channel to the alpha channel, as<br>
this makes some sense for the purpose of dust removal, while it can for<br>
example map UV-&gt;blue, IR-&gt;red, Radardata-&gt;green for a sattelite<br>
transmission.<br>
<p>
<i>&gt; Before you make this argument again, I want _evidence_ that we're going</i><br>
<i>&gt; to be swamped by more image formats.</i><br>
<p>
Read the post by that high-speed scanner guy. It already contained a big<br>
bunch of formats. And yes, I want them all supported, as his HW can deliver<br>
them. then look at cameras, look at picture archives (the pnm backend is a<br>
trivial example for it), look at TWAIN support, which requires us to support <br>
audio transfers, if we want to implement the spec fully, ...<br>
<p>
If that ain't enough examples to prefer a 3-frametype approach over a 30+<br>
frametype approach, I can't be of any help here. Sorry. Neither for V2 nor<br>
for the TWAIN bridging.<br>
<p>
And regarding evidence: If I had any _evidence_ of the future, I would be a<br>
very rich man and wouldn't hang around here.<br>
<p>
<i>&gt; Further, I think SANE's use of standards-based formats (like JFIF)</i><br>
<i>&gt; is important because SANE is also a Free Software project. </i><br>
<p>
This is a purely political argument, which should never be used for code<br>
design. And it should never be used without reading up the spec in question.<br>
MIME promotes exactly that. O.K. - you may define the "x-" types as you<br>
wish, but that can be done with any system. If a vendor wants to break <br>
stuff, he can just transmit on frametype "4711" and has the same effect.<br>
It has been done to /etc/services, and include/sane/frametypes.h won't <br>
make a difference.<br>
<p>
<i>&gt; Wherever we have a choice we should encourage Open standards rather than</i><br>
<i>&gt; Proprietary technology. In the backend we have little choice, but</i><br>
<i>&gt; in the SANE protocol and API we *do* have a choice.</i><br>
<p>
Stop that unreasonable argument. Read the MIME spec, then talk about it.<br>
The encoding of the frametype has _NOTHING_ to do with Open standards or<br>
Proprietary technology. On the contrary, inventing our own thing would mean<br>
setting yet another "standard", which really doesn't promote open standards.<br>
Standards are only of use, if everyone uses them.<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="0283.html">Cooper: "Re: Machine lock-ups while scanning. HP scanjet 5P/BusLogic Flashpoint"</a>
<li> <b>Previous message:</b> <a href="0281.html">Oliver Rauch: "Re: UMAX parallel port scanner"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>