[sane-devel] Sane API

[Povilas Kanapickas]

Hi all,

On 10/20/20 11:12 AM, Alexander Pevzner wrote:
> 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 seems to me that this would be relatively independent of the current
APIs, wouldn't it? We can add the new APIs to SANE 1.1 and applications
could preserve backwards compatibility by optionally using them via dlsym.

> - 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
> 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

We could add SANE_Devicev2 and sane_get_devices_v2 APIs in a
backwards-compatible way. New applications could dlsym the new API from
new backends, old applications could continue using the old APIs.

> 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)

(I've copied this from another e-mail, sorry for duplication and being
late to the party :-) )

We already have "x-resolution" and "y-resolution" options. X/Y
resolutions can be handled the same way the non-pecific "resulution"
option is handled right now. That is, application sets the preferred X
and Y resolutions and then must check what actual supported resolution
was selected by the backend by querying these options again.

> 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

A string option for a scan source is much more flexible than e.g. an int
and should be preserved. What we probably need is just document the
commonly used values in the existing standard.
> 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).

Agreed. This case is more difficult. We need a way to preserve both the
old and new behavior in some way with a possibility for the scan
application to request either on demand.
> 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.

This can be implemented as a special "color" mode in existing standard.
We would probably need an additional API for that.

Cheers,
Povilas