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

[Alessandro Zummo]

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.

 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.

 Adding a flag means that only new frontends that can handle this flag
 will keep the option hidden. On the other side my method would

 a) do no harm to existing backends/frontends
 b) be extremely easy to implement in a frontend

 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.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it