[sane-devel] demo patch for SANE 1 / SANE 2 coexistence

Johannes Meixner jsmeix at suse.de
Fri Nov 14 11:35:00 UTC 2008


Hello,

On Nov 13 22:11 stef wrote:
> in order to demonstrate the possibility to have SANE 1 and SANE 2
> coexisting by using meta backends, here's a demo patch against
> recent CVS which:
> - raise V_MAJOR to 2
> - add a sane1 meta backend that loads backends with a so major of 1 to
>   allow SANE 2 frontends to use SANE 1 backends
> - add a sane2 meta backend with a so major of 1 but searches for backends
>   with a so major of 2. It also handles the warming up status, and detects
>   use of newer frame formats. So a SANE 1 frontend would be able to use a
>   SANE 2 backend.
>
> So even after an installation of SANE 2 packages:
> - SANE 1 only backends such as binary one can still be used
> - SANE 1 frontends can use SANE 2 backends
> This let package maintainers to upgrade at their will and/or
> when frontends get updated to take advantage of new features.
> Custom or binary frontends won't need to be updated.

Regarding the names of the compatibility meta backends:

I wonder if your naming scheme is future-proof so that
it would also work to have SANE 1, SANE 2, SANE 3,...
coexisting?

I assume that in a short time after SANE 2
new features require SANE 3, SANE 4,...

I think it is perfectly o.k. to just raise the major
version number if there is a incompatibility so that
development can just move forward without the need
to have a never-ending discussion to make the next
version "the last final solution forever".

But then there must be a future-proof method
how to keep backward compatibility.

Therefore I suggest to have a more verbose naming scheme
for the compatibility meta backends with two numbers:

- one is its own version number (i.e. the version
   number which match to the frontend which links
   with this compatibility meta backend)

- the other one is the compatibility version number
   (i.e. the version number which match to the backend
   which is linked by this compatibility meta backend)

So that
- a sane2_1 compatibility meta backend loads backends
   with a so major of 1 to allow SANE 2 frontends
   to use SANE 1 backends
- a sane1_2 compatibility meta backend loads backends
   with a so major of 2 to allow SANE 1 frontends
   to use SANE 2 backends

And for the future
- a sane3_1 compatibility meta backend loads backends
   with a so major of 1 to allow SANE 3 frontends
   to use SANE 1 backends
- a sane3_2 compatibility meta backend loads backends
   with a so major of 2 to allow SANE 3 frontends
   to use SANE 2 backends
- a sane1_3 compatibility meta backend loads backends
   with a so major of 3 to allow SANE 1 frontends
   to use SANE 3 backends
- a sane2_3 compatibility meta backend loads backends
   with a so major of 2 to allow SANE 2 frontends
   to use SANE 3 backends


By the way:

What about saned and the net meta backend?

Are compatibility saneds and compatibility net meta backends
also needed, e.g. when on the server SANE 1 runs but
on the client already SANE 2 (servers are usually
not as often upgraded than client workstations)
and/or vice versa?


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex



More information about the sane-devel mailing list