> > Well, Andreas seems primarily to be concerned about indentifying a frame
> > type to the user in the event that it's not natively understand by an
> > old backend.
>
> No. I am concerned about being able to upgrade a frontend without
> even recompiling. Enums are very bad to do this. Yes. One can make
> a mapping database that maps the numeric values, but that's not terribly
> descriptive or readable afterwards, and thus not maintainer friendly.
"Upgrade a frontend without even recompiling" ?
Presumably you mean that MIME types will allow you to indentify the type
of data, and magically learn how to do something useful with it? This is
fantasy, though doubtless it's nice to dream.
I spent an hour the other day trying to get PNG (popular, standard and
officially included in MIME years ago) properly identified by our main
web servers, bought this year. No surprise that /etc/mime.types doesn't
have any useful entries past 1996 on any machines I used.
> Binary compatibility is something very important to mainstream software
> that has many many contributors, and even eventually commercial contributors
> in future.
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.
> 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.
Vendors themselves will no doubt include a working frontend in the box,
if they start making SANE backends for themselves.
> So we double-transfer the datatype ?
>
> And miss the opportunity to be able to ask without further configuration:
> Save, Open using 'program xxx', or ignore frame ?
Fantasy again. The configuration for all this will either have to be done
by SANE (in which case MIME is irrelevant) or by the system itself. I see
no evidence of this "Open using..." feature on any Unix machines. In
fact I don't even see "image/png" listed, and "image/jpeg" isn't on all
the machines.
> I have seen the proposals up to now. Already too much for my taste.
There is too much crap in MIME for my taste. Compromise.
> I simply hate doing double work, and using that "short description" you
> propose is exactly that. You seem to be concerned about having precisely
> defined standards for each image type. O.K. - where is the problem ?
> Do you think we can do better than the IANA ?
IANA had a different problem, and MIME is a very good solution to that
problem (though it has its flaws). Our problem has totally different
constraints, and so I reject MIME as a solution because it was never
meant for this, and it shows.
> The MIME RFC specifies, that new types need to be passed by IANA and need to
> point to an open specification of the content that is in an RFC or proposed
> RFC.
Question for Andreas: Do you propose
(1) To allow only "image/blah", image formats with an open specification
which have survived the somewhat slow RFC application process?
(2) As above, but with the further constraint that the formats should
be listed in /etc/mime.types or equivalent on SANE systems?
(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?
> Using the system I favour, this is a matter of a very simple configuration
> file that will just map a transmitted IR channel to the alpha channel, as
> this makes some sense for the purpose of dust removal, while it can for
> example map UV->blue, IR->red, Radardata->green for a sattelite
> transmission.
Configuration files for a frontend which maps data channels aren't part
of SANE. The IR channel should never be in "alpha", any more than the
red should be in "green". Sure, it makes your code simpler, but it
breaks interoperability, and if you don't care about that why use SANE?
> Read the post by that high-speed scanner guy. It already contained a big
Which "post by that high-speed scanner guy"? The one with the G series
fax protocols? That came down to three formats, each significantly
different. None of them are in MIME AFAIK, so in MIME you'd have to
encapsulate them somehow, which <sigh> would mean most apps can't load
them when your magical frontend has saved the encapsulated form.
> bunch of formats. And yes, I want them all supported, as his HW can deliver
> them. then look at cameras, look at picture archives (the pnm backend is a
> trivial example for it), look at TWAIN support, which requires us to support
> audio transfers, if we want to implement the spec fully, ...
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?
We don't want to "implement the spec fully" because that's far beyond the
remit of SCANNER ACCESS NOW EASY and into fairy land. You said yourself
that TWAIN is several hundred pages long.
> If that ain't enough examples to prefer a 3-frametype approach over a 30+
> frametype approach, I can't be of any help here. Sorry. Neither for V2 nor
> for the TWAIN bridging.
You could be of a little help before you leave by fixing the PNM backend
> Stop that unreasonable argument. Read the MIME spec, then talk about it.
> The encoding of the frametype has _NOTHING_ to do with Open standards or
> Proprietary technology. On the contrary, inventing our own thing would mean
> setting yet another "standard", which really doesn't promote open standards.
> Standards are only of use, if everyone uses them.
We already have our own standard for this. I don't want to add another one,
and you want MIME, which I've already showed to be unsuitable.
Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com