The process through which a SANE frontend connects to a backend is platform dependent. Several possibilities exist:
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.#define sane_read be_sane_read
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.
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.