[sane-devel] permission request

[m. allan noah]

On Dec 19, 2007 9:41 AM, Colin Hogben <sane at pythontech.co.uk> wrote:
> 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...

no- the more the merrier :)

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

i think the idea is nice in principal, though the specifics of using
the obfuscated version number are not that pleasant.

at this moment, my prime concern is extending the standard in a way
that might require front-ends to be updated a little, but will not
require them to support two versions of sane.

if we reach a point where we are prepared to extend the API in an
incompatible way, then we can address the mechanism for identification
of version.

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