[sane-devel] demo patch for SANE 1 / SANE 2 coexistence
Hello, here's a variant to make SANE 1/SANE 2 coexist in the case of dynamic linking. dll.c is modified to search for backend with a soname of 2 first, and in case of failure, it searches backend a a 1 soname. This way if an out-of-tree backend in installed, it will still be usable by a SANE 2, and automaticaly searched and found. To allow SANE 1 frontends using SANE 2 backends, there is still a sane2 meta backend that is linked and installed with a 1 soname by the SANE 2 build system. This meta backend takes care of the SANE 1/SANE 2 API differences. I have also tested that copying this libsane-sane2.so.1 library as libsane.so.1 (overwriting the one from sane-1.0.19) allowed a SANE 1 frontend to detect and use SANE 2 backends installed without prefixing the device name with 'sane2'. So by tweaking the install process of SANE 2, SANE 1 installation would be able to use SANE 2 backends without any change. Regards, Stef -- next part -- A non-text attachment was scrubbed... Name: demo2.gz Type: application/x-gzip Size: 12163 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20081118/18bb7ecc/attachment-0001.bin
[sane-devel] demo patch for SANE 1 / SANE 2 coexistence
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
[sane-devel] demo patch for SANE 1 / SANE 2 coexistence
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:
[sane-devel] demo patch for SANE 1 / SANE 2 coexistence
Hello, 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. Regards, Stef -- next part -- A non-text attachment was scrubbed... Name: demo.patch.gz Type: application/x-gzip Size: 20141 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20081113/d6aa65b4/attachment.bin
