[sane-devel] SANE2 standard completion

[Julien BLACHE]

É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.

JB.

-- 
Julien BLACHE                                   <http://www.jblache.org> 
<jb at jblache.org>                                  GPG KeyID 0xF5D65169