[sane-devel] Sane API

[Jürgen Mellinger]

Hi Alex,

> Am 20.10.2020 um 18:59 schrieb Alexander Pevzner <pzz at apevzner.com>:
> 
> Hi Jürgen,
> 
> On 10/20/20 7:40 PM, Jürgen Mellinger wrote:
>> I would like to add "mssing option to poll ADF state" to what is missing from the current API.
>> With the current API, it is not possible to prompt the user with meaningful messages such as "please put a document into the ADF" vs "there is a paper jam in the ADF" and similar.
> 
> From my experience with eSCL/WSD scanners
> 1) Polling current ADF state BEFORE scan attempt is not reliable
> 2) Reporting of ADF-related errors AFTER failed scan attempt is reliable

If so, how does a typical client application behave without confusing the user?
Independently of eSCL/WSD, how would one want a frontend behave when talking to a SANE driver?
-Jürgen

> 
>> —Juergen
>>> Am 20.10.2020 um 10:12 schrieb Alexander Pevzner <pzz at apevzner.com>:
>>> 
>>> 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.
>>> - 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
>>> 
>>> 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)
>>> 
>>> 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
>>> 
>>> 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.
>>> 
>>> My list is most likely very incomplete.
>>> 
>>> -- 
>>> 
>>> 	Wishes, Alexander Pevzner (pzz at apevzner.com)
>>> 
> 
> 
> -- 
> 
> 	Wishes, Alexander Pevzner (pzz at apevzner.com)
>