[sane-devel] Sane API

[Alexander Pevzner]

Hi,

On 10/20/20 6:04 PM, Ralph Little wrote:
> b) We have new (fairly open) standards being introduced which offer the
> possibility that we could get wide compatibility in Linux. As a
> consequence, we have a number of machines supporting a number of
> different protocols provided by different backends. I have no doubt that
> manufacturers will coalesce their support around these new protocols
> because it makes economic sense for them to do so.

I want to outline one thing, that I feel is quite important.

When SANE project has started a while ago, the software model of scanner 
(scanner as an object that provides some software interfaces) was 
roughly the following:
1. Scanner is a device that somewhere physically exists
2. It has a name, that helps human user to physically identify it
3. It can scan, and scanning returns an image
4. Scanning may take a while and user may want to cancel the process
5. Scanning may fail, returning some of the few predefined error codes
6. Scanner has options. These options have user-readable names and 
user-editable values (user == human user here)

Though this model is very progressive in comparison to TWAIN approach of 
that time, where scanner was an object that opens unsolicited UI 
windows, it still not enough.

Most important missed things are:
1. No common vision of scanner options
2. No PnP
3. No support of custom error/status messages. Existing set doesn't 
cover all situations that actually exist and is not expandable without 
breaking compatibility
4. No access to image formats, directly generated by hardware
5. No way to identify the situation, when the same device is discovered 
by multiple backends
6. No way to merge printer and scanner parts of the same physical device

Now we have two published standards that codify scanner as a 
programmable object: IPP-scan and WSD. If you skip unimportant details, 
like units to specify image size (1/1000 inch in WSD, 1/100 mm in IPP), 
or detailed specification of scan-to-email, which you will find in the 
IPP-scan standard, you will notice that software models for scanner 
itself is very similar between these two standards. And this is quite 
similar to the eSCL model, though eSCL is not published, and to the 
TWAIN Direct, yet another HTTP+JSON-based published standard for the 
"driverless" scanning.

So a giant work was done for us by codifying scanner object with all it 
possible options, scan job flow and a lot of nuances.

Obviously, all future mass-market scanners will follow this model, 
because manufacturers will want to support eSCL/WSD.

I think, our future API specification should borrow scanner definition 
model from these standards. Though it will not solve all the problems 
I've listed, it will solve at least half of them.

And well, I believe our goal is to make Linux a first-class operating 
system in respect to scanning. We should scan better, that Windows/MacOS 
ever did! :-)



-- 

	Wishes, Alexander Pevzner (pzz at apevzner.com)