[sane-devel] Sane API

[Steven Santos]

I do documentation, not development, so take this for what its worth.

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.

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.

3. The need for middleware has been established.

I think the path forwards is to allow sane and sane2 to sit side-by-side.

Sane1 should be left in its current state, exposing its drivers to sane2
via its net backend.

Sane2 should act as a front end for sane 1, taking those scans and
delivering them to its middleware.

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.

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.





On Mon, Oct 19, 2020 at 9:05 AM Alexander Pevzner <pzz at apevzner.com> wrote:

> 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)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20201019/10928312/attachment-0001.html>