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
