> On Tue, 24 Aug 1999, Oliver Rauch wrote:
>
> > Hello Nick,
> >
> > In my opinion Andreas is right that it is a bad idea to
> > add each frame format to enum SANE_FRAME_*.
> > It is much more simple to extend the standard to support
> > new formats when we define the frame format in a string.
>
> I'm not entirely sure I agree about that, but let's see where this is
> going...
>
> > The question is if the string has to be a string defined by MIME.
> > I did not read the MIME specs but as far as I know there are
> > a lot of formats listed and MIME allows to extend the definition
> > by eXperimental types.
>
> The enum based proposals so far cover:
> JPEG (JFIF), JBIG (?), G31D, G32D, G42D
>
> MIME has a recognised type for JPEG and both G3 variants, however the
> G3 MIME type isn't very helpful for our purposes, because it relies
> on MIME headers for the G3 parameters, including encoding. I don't
> know yet (see previous mail) if JBIG should be in SANE V2, but if it
> is, there's no MIME type for that either.
>
> > So the question is do we define a new standard that has to be
> > extended step by step in the future or do we use a subset of an
> > existing standard.
>
> I think we should extend the existing standard, by adding more frame
> types. I'm open to suggestions about encoding them in some other way
> rather than by using integers, but note that this will mean SANE 1.0
> cannot interoperate usefully with SANE 2.0
If we call it sane-2.0, the sane-1.0 standard already says to it:
: Whenever a change
: to the SANE standard is made that may render an existing frontend or
: backend incompatible with the new standard, the major version number
: must be increased. Thus, any frontend/backend pair is compatible
: provided the major version number of the SANE standard they implement
: is the same. A frontend may implement backwards compatiblity by
: allowing major numbers that are smaller than the expected major number
: (provided the frontend really can cope with the older version). In
: contrast, a backend always provides support for one and only one
: version of the standard.
There are other planned extensions that make it necessary to
change the major version of the sane standard.
E.g. it is interesting to add some flags (e.g. multiple images available),
to the parameter block and to add values for x_dpi, y_dpi and
some other things.
Because the frontend does allocate the memory for the parameter
block there is no way that an old frontend can work with a new backend.
So if we will add anything to the parameter block we have to make sane-2.0
and not 1.02 or whatever.
If we already do that there is no need to add the new frames in a compatible
way to sane-1.0.
>
> > We also could say we use the mime type definitions where they
> > make sense so frontends and other applications can take
> > advantage of this and we define our own definitions
> > like "sane/rgbi" where this makes sense.
>
> If we're sticking with MIME types that should be image/vnd.sane.rgbi
> This sort of mistake is why I had no confidence in the opinions Andreas
> gave about MIME's utility for SANE.
>
> I don't understand why MIME is thought to help us solve problems when
> the only well-known type it shares with SANE is "JPEG", and IANA
> seem less and less interested in adding well standardised MIME types,
> preferring the vendor-specific name space.
Please let us do the discussion about MIME or not MIME
do when the rest of the standard is defined. This discussion
is not constructive in the moment.
Bye
Oliver
-- EMAIL: Oliver.Rauch@Wolfsburg.DE WWW: http://www.wolfsburg.de/~rauch
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com