Re: Starting a discussion about SANE and TWAIN...

Henry Miller (hank@black-hole.com)
Sat, 14 Aug 1999 23:04:25 -0500 (CDT)

On Sun, 15 Aug 1999, Nick Lamb wrote:

>
> On Sat, 14 Aug 1999, Stephen Williams wrote:
>
> > So all I'm looking for at the moment is some sort of means to negotiate
> > frame formats.
>
> Ok. IIRC Your scanners can do RGB, but prefer not to for speed reasons?
> So in writing the backend, first start by supporting this (slow) option
> as the default and then add an option (eventually to be a well-known
> option in SANE 2.0) which controls the compression.

We really need more extensiablility, preferabliy so that the future can be
added without a Sane version 3.0. (this is an ideal, not nessicarly
achivable in practice.

Looking to telnet, you have a default mode that everything needs to
support. there is also a "Will/ Won't, Do/Don't" protocol that can be
extended as needed, this is entirly behind the users back.

I'm proposing adding a similear layer of non-viewbale controls. A backend
supports everything in Sane 1.0, plus the non-user protocol. If the
backend prefers jpeg, it can send "I will do jpeg" (which is probably a
numerical value) and the frontend responds "Do jpeg", or "Don't jpeg"

Anouther backend might offer to send a dust channel, (by a protocl defined
in whatever standard defins the dust collection) and if the frontend
refuses, it just sends RGB, otherwise it sends the dust channel by some
means.

There also needs to be middle laywer commands, for instance the net
connection might want to negociate compression. Normally this is
reasonable, but if the backends are sending jpeg it should not. Thus, is
all options are refused between ultimate front end and backend, then mid
layers can do something, if there is an option allowed, the mid layers
should not do anything unless told to. The dust colletion option
could result in a backend sending a command "I don't do do compression,
but you can". If the mid layer happens to understand the dust collection
it could still do something else that it the other ends don't know about
if compatable. Basicly, if you understand an option you can take whatever
action you want, if you don't understand one in effect you should take no
action.

I'm not sure if I ultimatly like the idea of conversion layers, but in the
above example, a frontend could refuse dustcollection, at which point the
conversion layer steps in and affers to do that correction. (at which
point it might negate the compression option already agreed to, because it
doesn't understand compression even though the other layers do)

I'm Not sure if that makes sense, but I hope you can get the idea: This
is a more flexable alternative, and every layer can take part. It is not
of course perfect, so I won't be mad if you pick it apart.

--
      http://www.black-hole.com/users/henrymiller/ 
      hank@black-hole.com

--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com