[sane-devel] Sane API

[Thierry HUCHARD]

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.