[sane-devel] SANE2 standard completion

m. allan noah kitno455 at gmail.com
Sun Mar 30 21:37:14 UTC 2008


On 3/30/08, Emmanuel Fust <emmanuel.fuste at laposte.net> wrote:
> > Message du 28/03/08 22:50
> > De : "Julien BLACHE"
> > "m. allan noah" wrote:
> >
> > Hi,
> >
> > >> - scanner's button handling
> > >
> > > this is overly complicated, and should be re-examined.
> >
> > For that and other reasons, 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, it can chat with other things (HAL, anything over D-Bus, you
> > name it) and we totally avoid the current side effects we have today.
> >
> > The more I think about it, the more I think this is the way to go.
> >
> > JB.
>
> Yes !!!!! I had the same feeling many years ago, twain like things with
> front end and backend coupling by libs/dlopen is a dead end.
> With saned, you could cleanly solve the  resource sharing problem, warm-up
> time pblm, tandby etc.... Your could have a clean network transport but
> nothing prevent you to have a locally optimized transport for data like
> shared memory buffers.
> And more interestingly, this net-oriented protocol could be designed with
> extensibility and backward compatibility in mind and saned could easily use
> directly all old V1 backends or native and rationalized new backend code. V1
> like api become and internal API which could evolve as needed.
> A new client (frontend) library could be developed and if someone really
> need it, it could expose a compatible v1 API/ABI (but it not worth it I
> think).

i have long considered such an idea, but it does not change the fact
that we have to design a new external API that provides access to
information that cannot be gotten thru the SANE1 API. Given the amount
of time i think that will take, this new saned wont meet the immediate
need.

As such, i would like to extend SANE1 just a little bit, and i dont
care if we call it SANE2 and give it a new soversion. Then, we can
spend all the time you guys want developing an extensible network
protocol, and turning saned into a real full-time daemon, because we
will have something that is easy for existing backends to use in the
meantime.

allan
-- 
"The truth is an offense, but not a sin"



More information about the sane-devel mailing list