[sane-devel] Sane API

[Thierry HUCHARD]

Hi All,

I went to quickly look at sane-2.0:
- I agree with @paddy-hack, making new with old is not necessarily a 
good thing!
- I found that the difference was in the options. The operations are 
identical. It will be easy for a developer to create a gateway from 
sane-1.0 to sane-2.0.
- The options are hardware dependent and there, some options are 
emulatable, others are not.
- If sane-2.0 is just the formatting of the options, why not do it in 
sane-1.0?

Thierry

Le 2020-10-19 22:35, Steven Santos a écrit :
> 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)