Hi, On 28.03.2008, at 19:09, Julien BLACHE wrote:
> ?tienne Bersac <bersace03 at gmail.com> wrote: > > Hi, > >> Do you mean having some cups for scanner ? > > Something much more simple than CUPS, but yeah, basically. > >> Actually, i wish not, because users don't want another service. HAL >> can >> launch addon per device which allow to launch nothing if no scanner >> present. > > Could you PLEASE stop thinking "HAL" all the time? I don't use HAL, I > don't want to use HAL, I don't need HAL for fsck's sake. > > Other OSes do not have HAL. > > HAL is, will be and must be an add-on, and nothing more. It must not > be either a dependency or a pre-requisite. > >> On the other end, scanner are more and more for professionnal which >> heavily use networked scanner, thus, having a protocol (like ipp for >> printing might be a good idea). But who will develop this ? How much >> years ? > > Based on the current saned, it can already be achieved: > - link saned statically to libsane-dll (what we know as libsane > today) > - ship libsane-net as libsane > - add a local connection to saned, typically a UNIX socket and listen > to that and that only unless general networking is explicitly > enabled. Ditto libsane only connects to the UNIX socket by > default. (the UNIX socket wins hands down against localhost/TCP) > > There, done. Keep all the underlying architecture as far as saned is > concerned. > > After that, implement whatever new feature you want in the > backends. The backends API is now a private API between saned and the > backends. Updates to the public SANE API as implemented by libsane > only requires changing libsane. As an added bonus, a compat layer can > probably be offered for current backends that cannot be modified. > > The network protocol will also probably need to change at some point, > I haven't thought about that particular point yet. More interactivity, > more status messages and the ability to feed scan data over a unique > TCP stream would be nice. > > User ACLs can be added to the mix. > > We're losing the ability to link an application to a backend directly > as is possible today, but it's seldomly use and we're getting rid of > those frigging side effects we have today. > > If we're redoing SANE, let's at least do it the right way. Investing > time and effort into something that'll only be marginally better than > what we have today makes no sense. +1 from me. Yours, -- Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name
