Le Friday 14 November 2008 12:35:00 Johannes Meixner, vous avez ?crit?:
> 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
Hello,
to my knowledge, there is no need for some specific net meta backend.
The net
meta backend allready loads all configured backends including the sane1/sane2
meta backends which then handle coexistence. For instance, after configuring
saned locally, a scanimage compiled with the demo patch gives the following
device list:
device `sane1:pnm:0' is a Noname PNM file reader virtual device
device `sane1:pnm:1' is a Noname PNM file reader virtual device
device `sane1:v4l:/dev/video0' is a Noname USB 2.0 Camera virtual device
device `pnm:0' is a Noname PNM file reader virtual device
device `pnm:1' is a Noname PNM file reader virtual device
device `pnm:locked' is a Noname Hardware locked virtual device
device `pnm:warmup' is a Noname Always warming up virtual device
device `v4l:/dev/video0' is a Noname USB 2.0 Camera virtual device
device `net:localhost:sane1:pnm:0' is a Noname PNM file reader virtual device
device `net:localhost:sane1:pnm:1' is a Noname PNM file reader virtual device
device `net:localhost:sane1:v4l:/dev/video0' is a Noname USB 2.0 Camera
virtual device
device `net:localhost:pnm:0' is a Noname PNM file reader virtual device
device `net:localhost:pnm:1' is a Noname PNM file reader virtual device
device `net:localhost:pnm:locked' is a Noname Hardware locked virtual device
device `net:localhost:pnm:warmup' is a Noname Always warming up virtual device
device `net:localhost:v4l:/dev/video0' is a Noname USB 2.0 Camera virtual
From a frontend compiled with SANE 1, the sane2 meta backend loads the
net
backend from SANE which in turn loads SANE2 backends, so device list looks
like:
....
sane2:net:localhost:pnm:warmup
....
While thinking of a SANE 3 and even a SANE 4 seems pretty far fetched
to me,
calling these possible meta backends sane2_1 and sane1_2 (or sane2to1 or
sane2from1, ...) is a non issue for me. It's just a name that can be chosen
freely to match what is needed.
Regards,
Stef
