kopia lustrzana https://gitlab.com/sane-project/website
166 wiersze
8.6 KiB
HTML
166 wiersze
8.6 KiB
HTML
<!-- received="Mon Aug 23 11:43:16 1999 PDT" -->
|
||
<!-- sent="Mon, 23 Aug 1999 19:48:34 +0100 (GMT)" -->
|
||
<!-- name="Nick Lamb" -->
|
||
<!-- email="njl98r@ecs.soton.ac.uk" -->
|
||
<!-- subject="Re: SANE V2" -->
|
||
<!-- id="" -->
|
||
<!-- inreplyto="19990823093615.A511@rz.uni-duesseldorf.de" -->
|
||
<title>sane-devel: Re: SANE V2</title>
|
||
<h1>Re: SANE V2</h1>
|
||
<b>Nick Lamb</b> (<a href="mailto:njl98r@ecs.soton.ac.uk"><i>njl98r@ecs.soton.ac.uk</i></a>)<br>
|
||
<i>Mon, 23 Aug 1999 19:48:34 +0100 (GMT)</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#284">[ date ]</a><a href="index.html#284">[ thread ]</a><a href="subject.html#284">[ subject ]</a><a href="author.html#284">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0285.html">Andreas Beck: "Re: SG_BIG_BUFF, glibc 2.1 weirdness ..."</a>
|
||
<li> <b>Previous message:</b> <a href="0283.html">Cooper: "Re: Machine lock-ups while scanning. HP scanjet 5P/BusLogic Flashpoint"</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
On Mon, 23 Aug 1999, Andreas Beck wrote:<br>
|
||
<p>
|
||
<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>
|
||
<i>> </i><br>
|
||
<i>> No. I am concerned about being able to upgrade a frontend without</i><br>
|
||
<i>> even recompiling. Enums are very bad to do this. Yes. One can make </i><br>
|
||
<i>> a mapping database that maps the numeric values, but that's not terribly</i><br>
|
||
<i>> descriptive or readable afterwards, and thus not maintainer friendly.</i><br>
|
||
<p>
|
||
"Upgrade a frontend without even recompiling" ?<br>
|
||
Presumably you mean that MIME types will allow you to indentify the type<br>
|
||
of data, and magically learn how to do something useful with it? This is<br>
|
||
fantasy, though doubtless it's nice to dream.<br>
|
||
<p>
|
||
I spent an hour the other day trying to get PNG (popular, standard and<br>
|
||
officially included in MIME years ago) properly identified by our main<br>
|
||
web servers, bought this year. No surprise that /etc/mime.types doesn't<br>
|
||
have any useful entries past 1996 on any machines I used.<br>
|
||
<p>
|
||
<i>> Binary compatibility is something very important to mainstream software</i><br>
|
||
<i>> that has many many contributors, and even eventually commercial contributors</i><br>
|
||
<i>> in future.</i><br>
|
||
<p>
|
||
Binary compatibility works. We discussed this, you said it wouldn't work,<br>
|
||
we explained it, you said it wouldn't work. We explained again, and you<br>
|
||
just ranted on about how lovely MIME is again. Please listen.<br>
|
||
<p>
|
||
<i>> Enums just do not work out on that. I've been through this on several</i><br>
|
||
<i>> projects. The constant upgrading of the .h files only ended when we went to</i><br>
|
||
<i>> much more general description schemes. And those projects had smaller scope</i><br>
|
||
<i>> to describe in the enum than image formats.</i><br>
|
||
<p>
|
||
image/vnd-ms-xb14 is useless to my application, because I'm not going to<br>
|
||
ask the user "please learn how to edit configuration files". Instead I<br>
|
||
will ask that they download a new version when they buy a new scanner.<br>
|
||
Vendors themselves will no doubt include a working frontend in the box,<br>
|
||
if they start making SANE backends for themselves.<br>
|
||
<p>
|
||
<i>> So we double-transfer the datatype ?</i><br>
|
||
<i>> </i><br>
|
||
<i>> And miss the opportunity to be able to ask without further configuration:</i><br>
|
||
<i>> Save, Open using 'program xxx', or ignore frame ?</i><br>
|
||
<p>
|
||
Fantasy again. The configuration for all this will either have to be done<br>
|
||
by SANE (in which case MIME is irrelevant) or by the system itself. I see<br>
|
||
no evidence of this "Open using..." feature on any Unix machines. In<br>
|
||
fact I don't even see "image/png" listed, and "image/jpeg" isn't on all<br>
|
||
the machines.<br>
|
||
<p>
|
||
<i>> I have seen the proposals up to now. Already too much for my taste.</i><br>
|
||
<p>
|
||
There is too much crap in MIME for my taste. Compromise.<br>
|
||
<p>
|
||
<i>> I simply hate doing double work, and using that "short description" you</i><br>
|
||
<i>> propose is exactly that. You seem to be concerned about having precisely</i><br>
|
||
<i>> defined standards for each image type. O.K. - where is the problem ?</i><br>
|
||
<i>> Do you think we can do better than the IANA ?</i><br>
|
||
<p>
|
||
IANA had a different problem, and MIME is a very good solution to that<br>
|
||
problem (though it has its flaws). Our problem has totally different<br>
|
||
constraints, and so I reject MIME as a solution because it was never<br>
|
||
meant for this, and it shows.<br>
|
||
<p>
|
||
<i>> The MIME RFC specifies, that new types need to be passed by IANA and need to</i><br>
|
||
<i>> point to an open specification of the content that is in an RFC or proposed </i><br>
|
||
<i>> RFC.</i><br>
|
||
<p>
|
||
Question for Andreas: Do you propose<br>
|
||
<p>
|
||
(1) To allow only "image/blah", image formats with an open specification<br>
|
||
which have survived the somewhat slow RFC application process?<br>
|
||
<p>
|
||
(2) As above, but with the further constraint that the formats should<br>
|
||
be listed in /etc/mime.types or equivalent on SANE systems?<br>
|
||
<p>
|
||
(3) To permit any MIME type to be allowed over the FRAME_MIME transport<br>
|
||
regardless of whether it has an experimental or vendor reserved prefix?<br>
|
||
<p>
|
||
<i>> Using the system I favour, this is a matter of a very simple configuration</i><br>
|
||
<i>> file that will just map a transmitted IR channel to the alpha channel, as</i><br>
|
||
<i>> this makes some sense for the purpose of dust removal, while it can for</i><br>
|
||
<i>> example map UV->blue, IR->red, Radardata->green for a sattelite</i><br>
|
||
<i>> transmission.</i><br>
|
||
<p>
|
||
Configuration files for a frontend which maps data channels aren't part<br>
|
||
of SANE. The IR channel should never be in "alpha", any more than the<br>
|
||
red should be in "green". Sure, it makes your code simpler, but it<br>
|
||
breaks interoperability, and if you don't care about that why use SANE?<br>
|
||
<p>
|
||
<i>> Read the post by that high-speed scanner guy. It already contained a big</i><br>
|
||
<p>
|
||
Which "post by that high-speed scanner guy"? The one with the G series<br>
|
||
fax protocols? That came down to three formats, each significantly<br>
|
||
different. None of them are in MIME AFAIK, so in MIME you'd have to<br>
|
||
encapsulate them somehow, which <sigh> would mean most apps can't load<br>
|
||
them when your magical frontend has saved the encapsulated form.<br>
|
||
<p>
|
||
<i>> bunch of formats. And yes, I want them all supported, as his HW can deliver</i><br>
|
||
<i>> them. then look at cameras, look at picture archives (the pnm backend is a</i><br>
|
||
<i>> trivial example for it), look at TWAIN support, which requires us to support </i><br>
|
||
<i>> audio transfers, if we want to implement the spec fully, ...</i><br>
|
||
<p>
|
||
I don't care about picture archives, the PNM backend is a DISGRACE and I'm<br>
|
||
glad you reminded to that it's still broken even though I reported the<br>
|
||
bugs LAST YEAR. Are you ever planning to fix it?<br>
|
||
<p>
|
||
We don't want to "implement the spec fully" because that's far beyond the<br>
|
||
remit of SCANNER ACCESS NOW EASY and into fairy land. You said yourself<br>
|
||
that TWAIN is several hundred pages long.<br>
|
||
<p>
|
||
<i>> If that ain't enough examples to prefer a 3-frametype approach over a 30+</i><br>
|
||
<i>> frametype approach, I can't be of any help here. Sorry. Neither for V2 nor</i><br>
|
||
<i>> for the TWAIN bridging.</i><br>
|
||
<p>
|
||
You could be of a little help before you leave by fixing the PNM backend<br>
|
||
<p>
|
||
<i>> Stop that unreasonable argument. Read the MIME spec, then talk about it.</i><br>
|
||
<i>> The encoding of the frametype has _NOTHING_ to do with Open standards or</i><br>
|
||
<i>> Proprietary technology. On the contrary, inventing our own thing would mean</i><br>
|
||
<i>> setting yet another "standard", which really doesn't promote open standards.</i><br>
|
||
<i>> Standards are only of use, if everyone uses them.</i><br>
|
||
<p>
|
||
We already have our own standard for this. I don't want to add another one,<br>
|
||
and you want MIME, which I've already showed to be unsuitable.<br>
|
||
<p>
|
||
Nick.<br>
|
||
<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="0285.html">Andreas Beck: "Re: SG_BIG_BUFF, glibc 2.1 weirdness ..."</a>
|
||
<li> <b>Previous message:</b> <a href="0283.html">Cooper: "Re: Machine lock-ups while scanning. HP scanjet 5P/BusLogic Flashpoint"</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|