kopia lustrzana https://gitlab.com/sane-project/website
153 wiersze
7.5 KiB
HTML
153 wiersze
7.5 KiB
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>> Well, Andreas seems primarily to be concerned about indentifying a frame</i><br>
|
||
<i>> type to the user in the event that it's not natively understand by an</i><br>
|
||
<i>> 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>> We can simply associate a short text string with each defined type, in</i><br>
|
||
<i>> the standard and in backend header files, and any frontend which can't</i><br>
|
||
<i>> handle the data format it receives (presumably because of a user</i><br>
|
||
<i>> advanced setting or badly behaved backend) will just look in the</i><br>
|
||
<i>> getparm results for "frame_description" and say...</i><br>
|
||
<i>> </i><br>
|
||
<i>> Sorry, I can't handle image data in the format:</i><br>
|
||
<i>> <insert short description here></i><br>
|
||
<i>> 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>> The other point which _keeps_ being made by proponents of MIME in this</i><br>
|
||
<i>> debate is that there will "inevitably" be a huge number of formats to</i><br>
|
||
<i>> support </i><br>
|
||
<p>
|
||
I have seen the proposals up to now. Already too much for my taste.<br>
|
||
<p>
|
||
<i>> -- 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>> or by looking at scanners "In the wild". The four new data formats</i><br>
|
||
<i>> (and two other formats) suggested by backend writers so far seem to</i><br>
|
||
<i>> 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->blue, IR->red, Radardata->green for a sattelite<br>
|
||
transmission.<br>
|
||
<p>
|
||
<i>> Before you make this argument again, I want _evidence_ that we're going</i><br>
|
||
<i>> 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>> Further, I think SANE's use of standards-based formats (like JFIF)</i><br>
|
||
<i>> 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>> Wherever we have a choice we should encourage Open standards rather than</i><br>
|
||
<i>> Proprietary technology. In the backend we have little choice, but</i><br>
|
||
<i>> 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 : <<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="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>
|