[sane-devel] Sane API

[Alexander Pevzner]

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 (pzz at apevzner.com)