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

Alessandro Zummo azummo-lists at towertech.it
Thu Feb 28 21:58:57 UTC 2008


On Thu, 28 Feb 2008 16:48:51 -0500
"m. allan noah" <kitno455 at gmail.com> wrote:

> >  >  > 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 :)

 I would, trust me, I would.. :-D

> >  >
> >  >   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.

 I just can't understand why we can't pretend that people uses switch
 correctly.

> >  >   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.

 Why an 1.1 COMPLIANT frontend should be allowed to compile against 1.0 SANE?

 I've never seen in my whole life any other library that has such
 a requirement. When the library version changes, you have to change
 the headers.

 
> >  >  > 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.

 My whole idea is to not use well known options for new things. We are forced
 to keep them, that's true, but if we want one day move toward a newer and
 better sane (1.x .. 2.0) with must evolve.. make little - non breaking - changes
 and keep evolving.

 sane is stagnating since ten years.. let's try a new way, let's try new things.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it




More information about the sane-devel mailing list