Hi Johannes,
On 10/19/20 3:41 PM, Johannes Meixner wrote:
I fear such a hard incompatible disruptive move forward might even
basically "kill" the SANE project in practice "out there".
I mean that it might annoy so many users in practice "out there"
that in the end "SANE doesn't work" might become a commonplace.
100% agree.
If SANE will break compatibility, I expect several months of resistance
from major Linux distros to upgrade to SANE 2.0 (while some
fixes/improvements will be backported from 2.0 to 1.0), and then fork
and creation of alternative with backward compatibility promises.
But please note also, there are not so much important SANE "clients"
(frontends) in existanse. I'm aware only about xsane, simple-scan and
LibreOffice. They can be easily fixed.
What is much more important and much harder to fix, is to prevent loss
of existent ~100 SANE 1.0 drivers (backends). Most of them are not
maintained and nobody will bother to rewrite them to support SANE 2.0 API.
To avoid that I think it is mandatory in practice that SANE 1 frontends
will continue to work as they did all the time so that for the users
there is no noticeable disruption in how things work for them.
This means all SANE 1 things must still be there in SANE 2
so that SANE 2 is a strict superset of SANE 1.
Actually, it is not necessery. It would be enough to have SANE 2.0
meta-backend (similar to sane-dll) that implements SANE 2.0
functionality on a top of SANE 1.0 API, exposed by existent SANE 1.0
backends.
Obviously, if something cannot be implemented, it will not be
implemented. But this is OK, because not everything we can imagine here
can be implemented on a top of ANY hardware, it will be the similar
limitation.
I made this proposal based on what I noitced how the CUPS library moved
forward
step by step as needed in the past without noticeable breakage of backward
compatibility, cf. the "someFunction" versus "someFunction2" names in
https://www.cups.org/doc/cupspm.html
Situation with SANE is more difficult, that with CUPS.
In CUPS, applications are linked against a single library. Old
applications use old API, new applications can use either new or old
API, as they wish.
In SANE, each backend is the SANE itself, and if you build your
application agains SANE library, that exposes sane2_init(), it will not
even load, if used with pure SANE 1.0 backend (or will crash at the
first call, depending on dynamic loader mode, either lazy or strict).
May be, SANE should withdraw its promise, that any backend could be used
alone as /usr/lib/libsane.so, and should explicitly state, that the only
backend, usable for apps, is libsane-dll, while libsane-dll will handle
all this complexity of providing emulations of sane2_xxx() functions for
backends that don't implement these functions natively.
--
Wishes, Alexander Pevzner ([email protected])
