[sane-devel] permission request

Colin Hogben sane at pythontech.co.uk
Wed Dec 19 14:41:21 UTC 2007


m. allan noah wrote:
> agreed- it seems that we have had so much trouble getting started on
> sane2 because it is so large and may have incompatibilites with sane1,
> making it hard to test. my idea was to move forward in smaller steps,
> trying to keep compatibility, so that old backends require no
> modifications.
>   
Excude me for jumping in having previously been only a lurker...

I completely agree - we are unlikely to get SANE2 off the ground if it 
requires an incompatible "big bang".  Section 4.1 of the SANE2 draft 
says "a backend always provides support for one and only one version of 
the standard", but I think this is the wrong approach.  Instead we 
should aim for a situation where:

* All backends continue to implement SANE1 interface.  So all existing 
frontends will continue to work with all backends.

* Any backend may also implement SANE2.

* A SANE2-capable frontend can determine whether or not a backend 
supports SANE2.

Note: SANE2-capability is a property of individual devices, not just 
backend classes - a meta-backend may need to support SANE2 for some 
devices but only SANE1 for others.

One immediate question: how could a SANE2-capable frontend determine 
whether a backend supports SANE2?  One possibility is that the 
sane_init() function returns a 'magic' value e.g. 
SANE_VERSION_CODE(1,255,0).  To a SANE1-only frontend, this appears as 
version 1; a SANE2-capable frontend will recognise the magic value and 
use SANE2 methods.

Another important point to allow smooth migration: we must not change 
existing interfaces (i.e. ABI) but we may augment them.  E.g. do not 
change the definition of SANE_Device (and therefore sane_get_devices()). 
instead, define SANE_Device2 structure with the new fields, and a new 
method sane_get_devices2() which returns them.

-- 
Colin Hogben




More information about the sane-devel mailing list