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
