[sane-devel] Passing all scanner usage through local saned

[thierryh at vivaldi.net]

Le 2024-05-11 07:19, Till Kamppeter a écrit :
> On 11/05/2024 02:54, Steven Santos wrote:
>> At this point, maybe we should be talking about if SANE is the correct 
>> long-term scanning solution for linux.
>> 
> 
> With printing we have gone completely to the industry standards: IPP + 
> DNS-SD With scanning we should do the same way.

It seems to me that this is the role of the sane-net backend.

> 
>> More or less, all modern scanners are supported by the eSCL backend, 
>> and will be going forward.
>> 
>> So why not standardize Linux scanning via eSCL?

As far as the eSCL protocol is concerned (as I've already pointed out), 
the capacities on display are lesser.
Admittedly, this will suit most users, but that won't always be the 
case, as of late: https://gitlab.com/sane-project/backends/-/issues/747

>> 
> 
> This is what I am suggesting/introducing. Apps find scanners via DNS-SD 
> and communicate with them via eSCL. This is exactly what sane-airscan 
> is doing and so we get this by sandboxing scanning frontend 
> applications together with sane-airscan. It can even later on happen 
> that eSCL client applications show up which do not use SANE any more 
> (but it is not urgent to create those, as long as the SANE API does not 
> apply a functional bottle neck to eSCL.
> 
>> It would seem to me that we could just develop a dummy scanner app to 
>> expose the current SANE and its drivers as an eSCL front end.
>> 
> 
> This "dummy scanner app" is what I call a retro-fitting Scanner 
> Application. Emulation of an eSCL scanner using PAPPL with Akarshan's 
> scanning support and using Akarshan's SANE-backend-retro-fit support 
> which he is adding to pappl-retrofit.
> 
>> One advantage to this is it would give us a path to support all TWAIN 
>> scanners on Linux via TWAIN Direct.  It would just be a matter of 
>> building a TWAIN Driect to eSCL in the same way.
> 
> For this we would need a Scanner Application which on its back side 
> speaks TWAIN Direct, and this running on Linux and ideally on any 
> operating system. We would ideally have the specification of TWAIN 
> Direct. Is this specification published? Or is it only available under 
> NDA for paying customers.Or do you think about reverse-engineering 
> here, as we have done with the many scanners with their proprietary 
> protocols do get SANE drivers for them? Reverse-engineering is 
> principally possible (we started eSCL this way, too) but always prone 
> to incompleteness and inaccuracy.
> 
> If somebody steps up doing this and implements it in a native 
> PAPPL-based Scanner Application, this would be great.
> 
> This also looks like that hardware manufacturers do three different 
> approaches for driverless scanning, eSCL, WSD, and TWAIN Direct. Here 
> we need to observe the market. eSCL seems to be the most commonplace, 
> WSD is also visible, but I do not know whether there are still many new 
> devices exclusively using it or whether it is turning legacy. WSD is at 
> least already supported, by sane-airscan. But is TWAIN Direct widely 
> made use of by the scanner industry? Does perhaps every scanner which 
> does TWAIN Direct also do eSCL and so TWAIN Direct gets redundant? Or 
> is TWAIN Direct even a nice name for actually being eSCL (or WSD or IPP 
> Scan)? We have a similar thing with printing. Driverless IPP printing 
> comes under the 4 names IPP Everywhere, AirPrint, Mopria, and Wi-Fi 
> Direct Print. Internally this is all the same.
> 
> So we need to investigate TWAIN Direct, how it internally works and how 
> widespread is its use.
> 
>    Till