[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