kopia lustrzana https://gitlab.com/sane-project/website
230 wiersze
11 KiB
HTML
230 wiersze
11 KiB
HTML
<!-- received="Mon Aug 23 17:40:07 1999 PDT" -->
|
||
<!-- sent="Tue, 24 Aug 1999 01:22:29 +0200" -->
|
||
<!-- name="Andreas Beck" -->
|
||
<!-- email="becka@rz.uni-duesseldorf.de" -->
|
||
<!-- subject="Re: SANE V2" -->
|
||
<!-- id="" -->
|
||
<!-- inreplyto="Pine.LNX.4.10.9908231850040.16541-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>Tue, 24 Aug 1999 01:22:29 +0200</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#286">[ date ]</a><a href="index.html#286">[ thread ]</a><a href="subject.html#286">[ subject ]</a><a href="author.html#286">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0287.html">Stephen Williams: "Re: SANE V2"</a>
|
||
<li> <b>Previous message:</b> <a href="0285.html">Andreas Beck: "Re: SG_BIG_BUFF, glibc 2.1 weirdness ..."</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
<i>> "Upgrade a frontend without even recompiling" ?</i><br>
|
||
<i>> Presumably you mean that MIME types will allow you to indentify the type</i><br>
|
||
<i>> of data, and magically learn how to do something useful with it? This is</i><br>
|
||
<i>> fantasy, though doubtless it's nice to dream.</i><br>
|
||
<p>
|
||
What is so fantastic about adding the line:<br>
|
||
<p>
|
||
# incoming type action transport filename<br>
|
||
image/pcx convertor pipe /usr/bin/pcxtoppm<br>
|
||
<p>
|
||
to a configfile ? If the frontend can make sense of a ppm, all is well,<br>
|
||
then. Of course I can do the same with<br>
|
||
<p>
|
||
# incoming type action transport filename<br>
|
||
23 convertor pipe /usr/bin/pcxtoppm<br>
|
||
<p>
|
||
with 23 being the frametype-number, but that's not awfully readable -<br>
|
||
is it ?<br>
|
||
<p>
|
||
But well - I won't argue that anymore. I'm really tired of it.<br>
|
||
<p>
|
||
<i>> Binary compatibility works. We discussed this, you said it wouldn't work,</i><br>
|
||
<i>> we explained it, you said it wouldn't work. We explained again, and you</i><br>
|
||
<i>> just ranted on about how lovely MIME is again. Please listen.</i><br>
|
||
<p>
|
||
[ Who is "we" ? Using pluralis majestatis ? Probably ... ]<br>
|
||
<p>
|
||
I don't give a damn about MIME or whatever you want to use instead. I'm just<br>
|
||
saying that a number (which an enum is) is about as undescriptive as it<br>
|
||
could be, and that the only reasonable way to support many frametypes on<br>
|
||
many frontends is to delegate the actual conversion of the frametypes to <br>
|
||
an external entity, like a bunch of conversion programs.<br>
|
||
<p>
|
||
This is only possible easily, if one can make some sense of the datatype<br>
|
||
descriptions easily. This is why /etc/services exists, this is why <br>
|
||
DNS exists, ... I can telnet 192.168.171.1 110, but telnet gate pop-3 <br>
|
||
is much nicer to deal with.<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>
|
||
<i>> image/vnd-ms-xb14 is useless to my application, because I'm not going to</i><br>
|
||
<i>> ask the user "please learn how to edit configuration files". Instead I</i><br>
|
||
<i>> will ask that they download a new version when they buy a new scanner.</i><br>
|
||
<p>
|
||
Great. Windows mentality. "How do I fix that ?" "_You_ don't. We will fix<br>
|
||
it for you." "When ?" "Maybe next release ...".<br>
|
||
<p>
|
||
<i>> Vendors themselves will no doubt include a working frontend in the box,</i><br>
|
||
<i>> if they start making SANE backends for themselves.</i><br>
|
||
<p>
|
||
And we will not be able to use them properly and easily with the free<br>
|
||
frontends, even if they spit out some reasonable format, unless we start<br>
|
||
hacking sourcecode and recompile.<br>
|
||
<p>
|
||
<i>> (1) To allow only "image/blah", image formats with an open specification</i><br>
|
||
<i>> which have survived the somewhat slow RFC application process?</i><br>
|
||
To recommend to use.<br>
|
||
<p>
|
||
<i>> (2) As above, but with the further constraint that the formats should</i><br>
|
||
<i>> be listed in /etc/mime.types or equivalent on SANE systems?</i><br>
|
||
It need not be listed anywhere. If you list it in a configfile, you can<br>
|
||
teach an old dog new tricks. And even if I am not able to put a few strings<br>
|
||
in a file I'd rather download a configfile than a complete new distribution.<br>
|
||
<p>
|
||
<i>> (3) To permit any MIME type to be allowed over the FRAME_MIME transport</i><br>
|
||
<i>> regardless of whether it has an experimental or vendor reserved prefix?</i><br>
|
||
Basically yes. Not recommended, but well - how would we hold them back ?<br>
|
||
They'll use Frame-type 72472, if they feel they want to. No matter what<br>
|
||
the spec says about that.<br>
|
||
<p>
|
||
<i>> Configuration files for a frontend which maps data channels aren't part</i><br>
|
||
<i>> of SANE. The IR channel should never be in "alpha", </i><br>
|
||
That has two split meanings:<br>
|
||
<p>
|
||
1. Right: It should never be _called_ alpha.<br>
|
||
2. But: It might make sense to _store_ it in the alpha channel of the<br>
|
||
outgoing picture.<br>
|
||
<p>
|
||
The latter makes for a very simple yet effective dust removal process,<br>
|
||
which will work with any layer capable pixel editing tool.<br>
|
||
[ You just copy the main Image into a second layer below the original.<br>
|
||
Then you apply a heavy despeckle filter to the copy, that would <br>
|
||
introduce artifacts in noisy structures. Due to the Alpha-information<br>
|
||
in the main image only the parts that were detected dusty will shine<br>
|
||
through, eliminating the artifacts in all good areas. ]<br>
|
||
<p>
|
||
<i>> I don't care about picture archives, the PNM backend is a DISGRACE and I'm</i><br>
|
||
<i>> glad you reminded to that it's still broken even though I reported the</i><br>
|
||
<i>> bugs LAST YEAR. Are you ever planning to fix it?</i><br>
|
||
<p>
|
||
NO. BECAUSE I HAVE NOT BROKEN IT in the first place. It was working all<br>
|
||
right before someone glued some "nifty" additions to it, that made it<br>
|
||
unwieldy and buggy. Actually it once was the reference-implementation.<br>
|
||
<p>
|
||
But o.k. - I think I have gotten your point finally. This is not a <br>
|
||
technical argumentation, but an "I am right because I am right".<br>
|
||
No use to try to set it straight. <br>
|
||
<p>
|
||
And I only fight for the life and physical integrity of myself and my<br>
|
||
friends. So I won't fight for that minor question on some kind of <br>
|
||
software.<br>
|
||
<p>
|
||
Please do as you wish to the SANE standard. It is my baby, and I really<br>
|
||
have a bleeding heart to leave it out there as helpless prey. I do not <br>
|
||
have the power to defend it, though part of me died here trying to.<br>
|
||
<p>
|
||
The standard is in the open, and I can't take my contributions back.<br>
|
||
And after all, that would not be my style. If that what will be left,<br>
|
||
helps someone, he shall make use of it as desired.<br>
|
||
<p>
|
||
But other than that, I am through with it. <br>
|
||
<p>
|
||
I wont f**king ever do something new for free software again. <br>
|
||
Thank you for finally giving me the last required kick to settle my mind <br>
|
||
on that topic. <br>
|
||
<p>
|
||
I have really had enough. <br>
|
||
<p>
|
||
This has now happened for the third time, and from now on, I will keep <br>
|
||
my ideas to myself, and make money from them. And heck - I know that it<br>
|
||
works. I rather take some money from a customer, than flames from anyone.<br>
|
||
<p>
|
||
Free Software is a very very nice idea. If not big egos were in the way, <br>
|
||
it would be much farther down the road.<br>
|
||
<p>
|
||
I really hate seeing such nonsense like a flamewar about using a number <br>
|
||
or a string to identify the type of a datastream, which is what this <br>
|
||
thread is all about.<br>
|
||
<p>
|
||
And I do not feel like wasting my time reading EMail that is basically<br>
|
||
telling me I'm a dumb as a rock. Maybe I am, but then I am no loss anyway.<br>
|
||
<p>
|
||
I really hope you all find someone that will <br>
|
||
- work 2 hours on a proposal for a new SANE V2.0 specification, <br>
|
||
- that will read 526 pages of TWAIN documentation to find out how one <br>
|
||
can properly interface the two standards,<br>
|
||
- that takes his time to debug very strange interactions in some weird <br>
|
||
SCSI stuff, <br>
|
||
- that reads others' proposals and comments on them in a constructive<br>
|
||
way,<br>
|
||
- that tries to help new users that show up with problems, <br>
|
||
- ...<br>
|
||
<p>
|
||
Sorry. You lost me. No bonus.<br>
|
||
<p>
|
||
<i>> that TWAIN is several hundred pages long.</i><br>
|
||
<p>
|
||
And I will not implement it. Period. I have the spec lying around here, I<br>
|
||
have put thought into it, and I have designed a way of interfacing the two<br>
|
||
standards. It's lying around here on my desk, and on my harddisk,<br>
|
||
waiting to be thrown away. I really hate wasted time.<br>
|
||
<p>
|
||
But I'm through with the arrogance that I feel here. <br>
|
||
<p>
|
||
It's definitely not the majority, but majority has to pay for it. Sorry.<br>
|
||
<p>
|
||
That's life. I always try to treat others, like they treat me - usually <br>
|
||
even with some extra bonus on the others' side. <br>
|
||
<p>
|
||
Attack me, and I will sidestep. But the don't try a second time unless you<br>
|
||
have seven lives. Your bonus is already wasted by then.<br>
|
||
Protect me, and I protect you. Don't care, and I won't care.<br>
|
||
<p>
|
||
Oliver: I wish you good luck with the TWAIN stuff. I really dispise <br>
|
||
letting you down on that. I know you kind of counted on me ...<br>
|
||
<p>
|
||
But I am only human, and I have a limited amount of nerves to strain <br>
|
||
and hair to pull. I won't waste any more of it. <br>
|
||
<p>
|
||
Of course you can make use of anything from my private EMails <br>
|
||
and put it to good use in the SANE/TWAIN bridge and/or an eventual <br>
|
||
SANE V2.0. Though I suppose it would be better to start over with<br>
|
||
the latter, as it seemingly is all wrong (you might want to try <br>
|
||
sed -e s/MIME/ARGL/ , though).<br>
|
||
<p>
|
||
<i>> You could be of a little help before you leave by fixing the PNM backend</i><br>
|
||
<p>
|
||
Thank you for that very helpful comment. I will not. Hunt down the guy who<br>
|
||
broke it. And even if I broke part of it, I wouldn't dare fixing it, as I'd<br>
|
||
probably do it all wrong. I'll better leave that to you.<br>
|
||
<p>
|
||
Hope you will enjoy my workload. I really enjoy loosing it.<br>
|
||
<p>
|
||
CU, Andy<br>
|
||
<p>
|
||
P.S.: No need to reply. unsubscribe is on its way, and EMail filtering is<br>
|
||
active.<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="0287.html">Stephen Williams: "Re: SANE V2"</a>
|
||
<li> <b>Previous message:</b> <a href="0285.html">Andreas Beck: "Re: SG_BIG_BUFF, glibc 2.1 weirdness ..."</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|