3.1 Attaching to a SANE backend

The process through which a SANE frontend connects to a backend is platform dependent. Several possibilities exist:

• Static linking: A SANE backend may be linked directly into a frontend. While the simplest method of attaching to a backend, it is somewhat limited in functionality since the available devices is limited to the ones for which support has been linked in when the frontend was built. But even so static linking can be quite useful, particularly when combined with a backend that can access scanners via a network. Also, it is possible to support multiple backends simultaneously by implementing a meta backend that manages several backends that have been compiled in such a manner that they export unique function names. For example, a backend called be would normally export a function called sane_read(). If each backend would provide such a function, static linking would fail due to multiple conflicting definitions of the same symbol. This can be resolved by having backend be include a header file that has lines of the form:

  #define sane_read be_sane_read
  

  With definitions of this kind, backend be will export function name be_sane_read(). Thus, all backends will export unique names. As long as a meta backend knows about these names, it is possible to combine several backends at link time and select and use them dynamically at runtime.

• Dynamic linking: A simpler yet more powerful way to support multiple backends is to exploit dynamic linking on platforms that support it. In this case, a frontend is linked against a shared library that implements any SANE backend. Since each dynamically linked backend exports the same set of global symbols (all starting with the prefix sane_), the dynamic library that gets loaded at runtime does not necessarily have to be the same one as one the frontend got linked against. In other words, it is possible to switch the backend by installing the appropriate backend dynamic library.

  More importantly, dynamic linking makes it easy to implement a meta backend that loads other backends on demand. This is a powerful mechanism since it allows adding new backends merely by installing a shared library and updating a configuration file.

• Network connection: Arguably the ultimate way to attach to a scanner is by using the network to connect to a backend on a remote machine. This makes it possible to scan images from any host in the universe, as long as there is a network connection to that host and provided the user is permitted to access that scanner.

Figure 1: Example SANE Hiearchy

The above discussion lists just a few ways for frontends to attach to a backend. It is of course possible to combine these solutions to provide an entire hierarchy of SANE backends. Such a hierarchy is depicted in Figure 1. The figure shows that machine A uses a dynamic-linking based meta backend called dll to access the backends called pnm, mustek, and net. The first two are real backends, whereas the last one is a meta backend that provides network transparent access to remote scanners. In the figure, machine B provides non-local access to its scanners through the SANE frontend called saned. The saned in turn has access to the hp and autolum backends through another instance of the dll backend. The autolum meta backend is used to automatically adjust the luminance (brightness) of the image data acquired by the camera backend called qcam.

Note that a meta backend really is both a frontend and a backend at the same time. It is a frontend from the viewpoint of the backends that it manages and a backend from the viewpoint of the frontends that access it. The name ``meta backend'' was chosen primarily because the SANE standard describes the interface from the viewpoint of a (real) frontend.