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

[Till Kamppeter]

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.

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

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