[sane-devel] SANE2 standard completion

[Emmanuel Fust]

> Message du 01/04/08 15:03
> De : "Johannes Meixner" <jsmeix at suse.de>
> A : sane-devel at lists.alioth.debian.org
> Copie à : 
> Objet : Re: [sane-devel] SANE2 standard completion
>
> 
> Hello,
> 
> On Mar 28 18:40 Julien BLACHE wrote (shortened):
> > ... I think it'd really be better to have the
> > frontends be entirely isolated from the backends, as I explained
> > already.
> > 
> > This would provide a central point (saned) handling the hardware
> > entirely
> 
> To avoid confusion with the cupsd, I like to mention that
> the cupsd does not talk to the hardware (i.e. the printer).
> 
> In CUPS there are so called "backends" which talk to the
> final destination of a print job (usually the printer but
> often also a network service like IPP, LDP, or SMB), see
> http://en.opensuse.org/SDB:CUPS_in_a_Nutshell
> 
> 
> Furthermore I like to mention that the HP printer and scanner
> driver HPLIP had in the past such a kind of daemon "hpiod"
> which did the actual hardware I/O.
> 
> There have been several drawbacks with such a daemon so that
> HPLIP dropped the daemon and uses now a library "libhpmud"
> which does the actual hardware I/O.
> 
> I.e. perhaps in the end a library is better than a daemon?
> 
> Perhaps the crucial question is not whether the hardware I/O
> is done via a library or via a daemon but to get the frontends
> be entirely isolated from the backends regardless if this is
> implemented via a daemon or via an additional I/O-library?
> 
> I think when a driver for all-in-one devices moved from
> a daemon to a library, it might indicate that this is also
> true for plain scanner drivers?
> 
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.

Sharing problem of multifunction device is another independent one and is already a problem today without saned.
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.
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.
And about daemon bloat: saned job would be very simple in comparison with a complete network spooling and document printing processing system like CUPS.

Cheers,
Emmanuel.

 Créez votre adresse électronique prénom.nom at laposte.net 
 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080401/e3450454/attachment.htm