[sane-devel] [RFC] how to enable 1.1 features

[m. allan noah]

On Thu, Feb 28, 2008 at 3:46 PM, Alessandro Zummo
<azummo-lists at towertech.it> wrote:
> On Thu, 28 Feb 2008 09:28:59 -0500
>  "m. allan noah" <kitno455 at gmail.com> wrote:
>
>  > in the fujitsu backend, i previously had added a 'compression' option
>  > with the description warning of possible front-end incompatibility,
>  > and the default setting to not compress. i feel this is sufficient,
>  > because it requires no changes at all to a well-written frontend.
>  >
>  > but, if you really want to protect this behaviour by requiring
>  > 'behind-the-scenes' frontend action, i would rather see a well-known
>  > option with its caps flags set to make them invisible. i think
>  > extending that flag (if required) is safer than adding macros or
>  > extending enums, because '==' tests are done on the caps instead of
>  > switch/case statements.
>  >
>  > i would also rather see this well-known option be named by the feature
>  > it implements, instead of a version name. By that means, a backend can
>  > add support for something particular, and a frontend can enable
>  > something particular.
>
>   Hi do not agree here. I'd like for both backends and frontends to
>   be "well-written". This is the whole point and I believe it
>   is perfectly reasonable.

but nothing about my suggestion will prevent authors from writing good code :)

>
>   In order to use a well known option, a frontend should track the option
>   by its name, doing strcmps on all the options, just like we are
>   doing now with corners.
>
>   In tiffscan I need to iterate on the options to find the four corners
>   because there is no other way to it. Saying that this is ugly is
>   not enough.

ah- but that's really where sane's power comes from- it is the
well-documented mechanism thru which we communicate about the features
of a backend. i see the support for additional frame types as just
another of these features.

>   Adding a flag means that only new frontends that can handle this flag
>   will keep the option hidden.

No, you misunderstand. the caps flag i would add would indicate that
the option could be set only by the frontend itself, all the other
bits would be set to indicate that the option was not user selectable,
and so, would be hidden in ALL frontends.

>  On the other side my method would
>   a) do no harm to existing backends/frontends
>   b) be extremely easy to implement in a frontend
>

my suggestion does even LESS harm to existing backends and front-ends,
cause you wont have to touch them at all!
and, it's even easier to implement in a front-end, since you already
have code to walk the options array and deal with the corner values :)

>   By declaring that you are sane 1.1 compliant you, the programmer,
>   are telling your users that you have put your efforts into making your
>   code robust, to check and handle error codes.

Ok, i'll buy that, so lets say that my well-known option should be
tied to the version number rather than the feature name, so how about
we call it 'sane-extension' or some such?

allan
-- 
"The truth is an offense, but not a sin"