On the one hand, scanning documents over the network seems to be there, but on the other hand, it has not become a common practice, unlike network printing. Administrators still install drivers, and remote scanning settings are individual for each scanner model. What technologies are available at the moment, and does such a scenario have a future.
Installable driver or direct access
Four types of drivers are currently common: TWAIN, ISIS, SANE, and WIA. Essentially, these drivers act as an interface between an application and a manufacturer's low-level library that is associated with a specific model.
Simplified scanner connection architecture
It usually means that the scanner is connected directly to the computer. However, no one restricts the protocol between the low-level library and the device. It could also be TCP/IP. This is how most network MFPs now work: the scanner is visible as a local one, but the connection goes through the network.
The advantage of such a solution is that the application does not care how the connection is made, the main thing is to see the familiar TWAIN, ISIS or another interface. No need to implement special support.
But the downsides are also obvious. The solution is tied to the desktop OS. Mobile devices are immediately dropped from support. The second disadvantage is that drivers can work unstable on complex infrastructures, for example, on terminal servers with thin clients.
The way out is to support direct connection to the scanner via HTTP/RESTful protocol.
TWAIN Direct
was proposed by the TWAIN Working Group as a driverless access option.
TWAIN Direct
The main idea is that all logic is transferred to the side of the scanner. And the scanner provides access via REST API. Additionally, the specification contains a description of the device publication (autodiscovery). Looks good. For the administrator, this is getting rid of possible problems with the drivers. Support for all devices, the main thing is that there is a compatible application. For the developer, there are also pluses, first of all, a familiar interaction interface. The scanner acts as a web service.
If we consider real use cases, then there are also disadvantages. The first is the deadlock situation. There are no devices on the market with TWAIN Direct and it makes no sense for developers to support this technology, and vice versa. The second is security, the specification does not impose requirements on user management, the frequency of updates to close possible holes. It is also not clear how administrators can control updates and access. The computer has antivirus software. And in the firmware of the scanner, in which there will obviously be a web server, this may not be. Or be, but not what the company's security policy requires. Agree, having a malware that will send all scanned documents to the left is not very good. That is, when this standard is implemented, the tasks that were solved by the settings of third-party applications are shifted to device manufacturers.
The third disadvantage is the possible loss of functionality. Drivers may have additional post-processing. Barcode recognition, background removal. Some scanners have so-called. imprinter - a function that allows the scanner to print on the processed document. This is not in TWAIN Direct. The specification allows the API to be extended, but this will lead to many native implementations.
And one more minus in scenarios of work with the scanner.
Scan from an application, or scan from a device
Let's take a look at how normal scanning works from within the application. I put down the document. Then I open the application and scan. Then I take the document. Three steps. Now imagine that the network scanner is in another room. You need to make at least 2 approaches to it. This is less convenient than network printing.
Another thing is when the scanner itself is able to send a document. For example, by mail. I put down the document. Then I scan. The document immediately flies to the target system.
This is the main difference. If the device is connected to the network, it is more convenient to scan directly to the target storage: folder, mail or ECM system. There is no place for a driver in this scheme.
From an outside perspective, we use network scanning without changing existing technologies. Moreover, both from desktop applications through the driver, and directly from the device. But remote scanning from a computer has not become as mainstream as network printing due to differences in work scenarios. Scanning to the right storage is becoming more popular.
Support for TWAIN Direct scanners as a replacement for drivers is a very correct step. But the standard is a bit late. Users want to scan directly from a network device, sending documents to their destination. Existing applications don't need to support the new standard because it still works just fine, and scanner manufacturers don't need to implement it because there are no applications.
In conclusion. The general trend shows that a simple scan of one or two pages will be replaced by cameras on phones. There will be industrial scanning, where speed is important, support for post-processing functions that TWAIN Direct cannot provide, and where tight software integration will remain important.
Source: habr.com