<div dir="ltr">I do documentation, not development, so take this for what its worth.<div><br></div><div>1. It seems to me that going forward, most scanners will be implementing some form if IPPEverywhere for scanners, so airscan et al is essentially the driver for most, if not all, modern scanners. </div><div><br></div><div>2. We have about 100 older scanner drivers that we need to preserve. Most of these are not currently maintained, and are unlikely to be maintained in the future.</div><div><br></div><div>3. The need for middleware has been established.</div><div><br></div><div>I think the path forwards is to allow sane and sane2 to sit side-by-side. </div><div><br></div><div>Sane1 should be left in its current state, exposing its drivers to sane2 via its net backend. </div><div><br></div><div>Sane2 should act as a front end for sane 1, taking those scans and delivering them to its middleware. </div><div><br></div><div>Going forwards, Sane2 drivers should be built against a standard libsane-dll type library, with standard middleware for controlling and tweaking the scans before being delivered to the front-end. </div><div><br></div><div>Sane2 would be installed by default as the scanning interface on linux, with only currently supported drivers.  Sane1 would be installed if legacy scanning is needed. </div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 19, 2020 at 9:05 AM Alexander Pevzner <<a href="mailto:pzz@apevzner.com">pzz@apevzner.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Johannes,<br>
<br>
On 10/19/20 3:41 PM, Johannes Meixner wrote:<br>
> I fear such a hard incompatible disruptive move forward might even<br>
> basically "kill" the SANE project in practice "out there".<br>
> I mean that it might annoy so many users in practice "out there"<br>
> that in the end "SANE doesn't work" might become a commonplace.<br>
<br>
100% agree.<br>
<br>
If SANE will break compatibility, I expect several months of resistance <br>
from major Linux distros to upgrade to SANE 2.0 (while some <br>
fixes/improvements will be backported from 2.0 to 1.0), and then fork <br>
and creation of alternative with backward compatibility promises.<br>
<br>
But please note also, there are not so much important SANE "clients" <br>
(frontends) in existanse. I'm aware only about xsane, simple-scan and <br>
LibreOffice. They can be easily fixed.<br>
<br>
What is much more important and much harder to fix, is to prevent loss <br>
of existent ~100 SANE 1.0 drivers (backends). Most of them are not <br>
maintained and nobody will bother to rewrite them to support SANE 2.0 API.<br>
<br>
> To avoid that I think it is mandatory in practice that SANE 1 frontends<br>
> will continue to work as they did all the time so that for the users<br>
> there is no noticeable disruption in how things work for them.<br>
> <br>
<br>
> This means all SANE 1 things must still be there in SANE 2<br>
> so that SANE 2 is a strict superset of SANE 1.<br>
<br>
Actually, it is not necessery. It would be enough to have SANE 2.0 <br>
meta-backend (similar to sane-dll) that implements SANE 2.0 <br>
functionality on a top of SANE 1.0 API, exposed by existent SANE 1.0 <br>
backends.<br>
<br>
Obviously, if something cannot be implemented, it will not be <br>
implemented. But this is OK, because not everything we can imagine here <br>
can be implemented on a top of ANY hardware, it will be the similar <br>
limitation.<br>
<br>
> I made this proposal based on what I noitced how the CUPS library moved <br>
> forward<br>
> step by step as needed in the past without noticeable breakage of backward<br>
> compatibility, cf. the "someFunction" versus "someFunction2" names in<br>
> <a href="https://www.cups.org/doc/cupspm.html" rel="noreferrer" target="_blank">https://www.cups.org/doc/cupspm.html</a><br>
<br>
Situation with SANE is more difficult, that with CUPS.<br>
<br>
In CUPS, applications are linked against a single library. Old <br>
applications use old API, new applications can use either new or old <br>
API, as they wish.<br>
<br>
In SANE, each backend is the SANE itself, and if you build your <br>
application agains SANE library, that exposes sane2_init(), it will not <br>
even load, if used with pure SANE 1.0 backend (or will crash at the <br>
first call, depending on dynamic loader mode, either lazy or strict).<br>
<br>
May be, SANE should withdraw its promise, that any backend could be used <br>
alone as /usr/lib/libsane.so, and should explicitly state, that the only <br>
backend, usable for apps, is libsane-dll, while libsane-dll will handle <br>
all this complexity of providing emulations of sane2_xxx() functions for <br>
backends that don't implement these functions natively.<br>
<br>
-- <br>
<br>
        Wishes, Alexander Pevzner (<a href="mailto:pzz@apevzner.com" target="_blank">pzz@apevzner.com</a>)<br>
<br>
</blockquote></div>