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.
Binary compatibility is something very important to mainstream software
that has many many contributors, and even eventually commercial contributors
in future.
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.
> We can simply associate a short text string with each defined type, in
> the standard and in backend header files, and any frontend which can't
> handle the data format it receives (presumably because of a user
> advanced setting or badly behaved backend) will just look in the
> getparm results for "frame_description" and say...
>
> Sorry, I can't handle image data in the format:
> <insert short description here>
> Save to a file anyway? (Y)es / No
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 ?
> The other point which _keeps_ being made by proponents of MIME in this
> debate is that there will "inevitably" be a huge number of formats to
> support
I have seen the proposals up to now. Already too much for my taste.
> -- yet this is hardly bourne out by an examination of MIME
I have read RFC 1341, 1521 and 1522. And I suggest you should do so, too,
before judging about the preciseness, the possibility of transferring
outband data or whatever on MIME.
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 ?
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.
Heck - they do all the work for us. Why waste it and set our own monument ?
> or by looking at scanners "In the wild". The four new data formats
> (and two other formats) suggested by backend writers so far seem to
> cover a broad range of high-end scanners.
Even that silly RGBI frame stuff is very inappropriate. The "I" is highly
unspecific.
The notion of using an Infrared channel as an alpha channel is highly
specific to the dust-reduction method using _transmitted_ IR. Reflected or
emitted IR like cameras deliver (and yes, I had such devices in my very
hands) are a completely different piece of cake.
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.
> Before you make this argument again, I want _evidence_ that we're going
> to be swamped by more image formats.
Read the post by that high-speed scanner guy. It already contained a big
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, ...
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.
And regarding evidence: If I had any _evidence_ of the future, I would be a
very rich man and wouldn't hang around here.
> Further, I think SANE's use of standards-based formats (like JFIF)
> is important because SANE is also a Free Software project.
This is a purely political argument, which should never be used for code
design. And it should never be used without reading up the spec in question.
MIME promotes exactly that. O.K. - you may define the "x-" types as you
wish, but that can be done with any system. If a vendor wants to break
stuff, he can just transmit on frametype "4711" and has the same effect.
It has been done to /etc/services, and include/sane/frametypes.h won't
make a difference.
> Wherever we have a choice we should encourage Open standards rather than
> Proprietary technology. In the backend we have little choice, but
> in the SANE protocol and API we *do* have a choice.
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.
CU, Andy
-- = 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