[sane-devel] Sane API

[Alexander Pevzner]

On 10/20/20 11:18 AM, Michael Starr wrote:
> Guys guys, just calm down. This is for Linux, remember?

Excuse me if I sound rude, I don't feel that and trying to be polite. 
English is not my native language so I can miss some nuances. Actually, 
I'm just trying to summarize things.

> Mike
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
> 
> *From: *Alexander Pevzner <mailto:pzz at apevzner.com>
> *Sent: *Tuesday, October 20, 2020 1:12 AM
> *To: *sane-devel at alioth-lists.debian.net 
> <mailto:sane-devel at alioth-lists.debian.net>
> *Subject: *Re: [sane-devel] Sane API
> 
> 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)