[sane-devel] SANE2 standard completion
Rene Rebe
rene at exactcode.de
Fri Mar 28 18:17:04 UTC 2008
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
More information about the sane-devel
mailing list