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

[m. allan noah]

resend to list- sorry alessandro-

On Thu, Feb 28, 2008 at 4:47 PM, m. allan noah <kitno455 at gmail.com> wrote:
> On Thu, Feb 28, 2008 at 4:20 PM, Alessandro Zummo
>
> <azummo-lists at towertech.it> wrote:
>
> > On Thu, 28 Feb 2008 16:03:23 -0500
>  >
>  > "m. allan noah" <kitno455 at gmail.com> wrote:
>  >
>  >
>  > > >   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 :)
>  >
>  >   but you are not going to induce them to do so :)
>
>  and neither are you :)
>
>
>  >  > >
>  >  > >   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.
>  >
>  >   frame types are completely different from well known options.
>  >   the existing mechanism has been a problem more than once.
>
>  just because they are not perfect does not mean that adding a new
>  interface is a better idea.
>
>
>  >  > >   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.
>  >
>  >   IF the frontend is compliant.... :)
>
>  ahh- but now you see the advantage of my approach- you wont find a
>  frontend that uses the caps in a switch/case, because its a bitmask.
>  so instead, they are doing macro == tests, so if the option does not
>  have SANE_CAP_SOFT_SELECT set, it wont display.
>
>
>  >  > >  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 :)
>  >
>  >   The fact that the code exists do not make it less ugly.
>
>  ah- it might not be perfect, but it MUST continue to exist, so lets
>  use it instead of adding a new interface, and requiring authors that
>  want their frontends to build against old sane to add ifndef's to
>  handle the missing new macros.
>
>
>  >  > >   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?
>  >
>  >   the problem is not the name, but the way. Options are - well - options.
>  >   supporting sane 1.1 is not an option :)
>
>  Ah- now i have you- you entire proposal is based around the idea of
>  making these features optional for backend/frontend combinations that
>  can support them. how are all other optional features in sane enabled?
>
>  the existing options interface.
>
>
>
>  allan
>  --
>  "The truth is an offense, but not a sin"
>



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