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