> Message du 01/04/08 15:03<BR>> De : "Johannes Meixner" <jsmeix@suse.de><BR>> A : sane-devel@lists.alioth.debian.org<BR>> Copie à : <BR>> Objet : Re: [sane-devel] SANE2 standard completion<BR>><BR>> <BR>> Hello,<BR>> <BR>> On Mar 28 18:40 Julien BLACHE wrote (shortened):<BR>> > ... I think it'd really be better to have the<BR>> > frontends be entirely isolated from the backends, as I explained<BR>> > already.<BR>> > <BR>> > This would provide a central point (saned) handling the hardware<BR>> > entirely<BR>> <BR>> To avoid confusion with the cupsd, I like to mention that<BR>> the cupsd does not talk to the hardware (i.e. the printer).<BR>> <BR>> In CUPS there are so called "backends" which talk to the<BR>> final destination of a print job (usually the printer but<BR>> often also a network service like IPP, LDP, or SMB), see<BR>> http://en.opensuse.org/SDB:CUPS_in_a_Nutshell<BR>> <BR>> <BR>> Furthermore I like to mention that the HP printer and scanner<BR>> driver HPLIP had in the past such a kind of daemon "hpiod"<BR>> which did the actual hardware I/O.<BR>> <BR>> There have been several drawbacks with such a daemon so that<BR>> HPLIP dropped the daemon and uses now a library "libhpmud"<BR>> which does the actual hardware I/O.<BR>> <BR>> I.e. perhaps in the end a library is better than a daemon?<BR>> <BR>> Perhaps the crucial question is not whether the hardware I/O<BR>> is done via a library or via a daemon but to get the frontends<BR>> be entirely isolated from the backends regardless if this is<BR>> implemented via a daemon or via an additional I/O-library?<BR>> <BR>> I think when a driver for all-in-one devices moved from<BR>> a daemon to a library, it might indicate that this is also<BR>> true for plain scanner drivers?<BR>> <BR>That's the point: CUPSD is a daemon regardless of implementation of the backend, daemon or I/O-lib. Nothing talk or invoke directly this io backend all talk to CUPSD via tcp or domain-unix socket in case of printing. It should be the case too for scanning via saned. io-backends should be internal API like in cups today.<BR><BR>Sharing problem of multifunction device is another independent one and is already a problem today without saned.<BR>It is linked to the capability of the device (not all could do print and scan at the same time) and could be cleanly addressed and hidden in the io-backend/driver with perhaps a little bit help from the saned/cupsd side and without breaking or touching the sane client side.<BR>Clean, simple, backward compatible and evolutive front end and backend isolation is way way simple to achieve and to maintain via a client/server based isolation than a library based isolation.<BR>And about daemon bloat: saned job would be very simple in comparison with a complete network spooling and document printing processing system like CUPS.<BR><BR>Cheers,<BR>Emmanuel.<BR><BR><i>Créez votre adresse électronique <a target=_blank href=http://www.laposte.net>prénom.nom@laposte.net</a> <BR> 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.</i><BR>