[sane-devel] sane 1.0.31 backend version not supported lineart. Why?...

[Ulf Zibis]

Hi,

I do not have any insight into the SANE architecture, but here are my thoughts for version 2 of SANE:

I like the idea of using a middleware.

Another approach could be to leave the lineart api at the backends, but replace the lineart emulation code in each backend by linking to a general library.

In both cases, additional parameters such as threshold could be helpful.

Some backends may have just copy/pasted the conversion code from each other and some may have there own code. so the general library should be parameterizable to emulate best the backends original behavior for maximum compatibility to the scan results, users are used to get.

So let SANE version 1 as is and maintain it in parallel. Bug fixes and new functionality state should be reflected in same minor version number, i.e. 1.0.31 should have the same functionality as 2.0.31.

-Ulf

Am 27.09.20 um 09:07 schrieb Olaf Meeuwissen:
>
> Same here.  Let the backend focus on getting images from the scanner
> that are as close as possible given the device's protocol constraints
> and limitations.  It can be hard enough already to get that working
> reliably according to the SANE API specification without having to deal
> with all kinds of software emulation.  Software emulation can be added
> on top of that via middleware (SANE calls this a virtual backend).  One
> place that might be suitable is the dll backend, however, things may be
> difficult to get right due to the fact that backends have so much leeway
> in naming their options.
>
> # Even the additional well-known options in the comatose version 2 draft
> # of the SANE Standard don't cut it.
>
>> [...]
>>
>> However, I guess I would make some observations:
>> 1) We could push the lineart conversion out of the backend, but there is no
>> middleware in which to implement it. The frontend would have to offer that
>> or leave it to the user to add it to their workflow outside of the scan
>> operation.
>> 2) If we remove it from a backend, then users consider that a regression,
>> and that's fair. So I think that we are stuck with it.
>> 3) I really dig the idea of having a sanei library of common operations. We
>> do have some copy/pasted conversions sprayed around the backends and it
>> would be great to get that code extracted out into something common, thus
>> reducing the code footprint of the backend. As ever, regression testing is
>> the issue for backends that are not well supported/maintained.
> # Radical idea: leave unmaintained backends just that, unmaintained.  We
> # might even disable their build by default so they stop holding hostage
> # any of the progress we might consider if it weren't for mortal fear of
> # introducing regressions.
> #
> # In terms of semantic versioning, we could split off a 1.x branch where
> # all the unmaintained backends remain and remove them from master for a
> # sane-backends-2.0.0.  Note, the version here is for the source tarball
> # and has *nothing* to do with SANE backend API versions and even less
> # with the SANE Standard version.
>
> Hope this helps,
> --
> Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
>   GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
>   Support Free Software                        https://my.fsf.org/donate
>   Join the Free Software Foundation              https://my.fsf.org/join
>