Le 2020-10-21 14:04, Thierry HUCHARD a écrit :
Le 2020-10-20 10:12, Alexander Pevzner a écrit :
Hi Thierry,
On 10/20/20 9:50 AM, Thierry HUCHARD wrote:
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?
Current API misses some essential things, that cannot be implemented
in terms of options:
- PnP notifications (scanner was connected/disconnected some time
after
driver was initialized). This limitation can be worked around by
continuous poll, but this poll drains a battery a generates
network/USB
traffic, so it is better to avoid.
I don't see why notifications should be made by sane.
It is the system that takes care of the connection / disconnection of
the devices!
USB is supported by udev
For the network, Cups detects the printers, rather than weighing down
the system it might be a good idea for Cups and Sane to propose a
common solution.
I remain convinced that it is not up to Sane or Cups to do this work
but to the system!
- If some scanner is identified by multiple backends, it would be nice
to let user app to automatically choose one of the list. For this
I'm for leaving the choice to the user, the automatic choice criteria
are generally subjective choice
criteria (specific to the developer), generally they limit the
possibilities.
purpose, it would be nice to expose some information regarding scanner
location, before scanner is opened (say, "USB bus X device Y, or NET
addr aaa.bbb.ccc.ddd). It requires adding extra fields to the
SANE_Device structure, which makes it incompatible with SANE 1.0
For the following things we just don't have appropriate
SANE_Value_Type:
- Scanner resolution if a form of X*Y pair. This is important, to
support "asymmetrical" resolutions (300*600, for example)
This change could easily be implemented without SANE-1.0.
Sorry :
This change could easily be implemented with SANE-1.0.
For the following options we don't have enough discipline:
- SANE_NAME_SCAN_SOURCE. There is no common names for ADF simplex/ADF
duplex, ADF front/ADF back
It's only discipline!
sane_airscan_get_parameters() must be accurate immediately after
return from sane_start(). It is not always possible, unless
sane_start() has to wait until image is available (compare sane-escl
and sane-airscan approach).
sane_airscan_get_select_fd() defined with serious mistake: it requires
backend to close select_fd immediately after completion or
cancellation of the scan job. In multi-threaded program closed file
descriptor could be immediately reused for some different purpose by
another thread.
There is no possibility to request image in the device-specific "raw"
format. I.e., if I want PDF and device can return PDF, image still
will be repacked PDF->sane format->PDF.
Indeed, sane_read should be allowed to return the scanner data without
processing it!
My list is most likely very incomplete.
