On Thu, 12 Aug 1999, Andreas Beck wrote:
> > Your comment about abstaction layers is of keen interest to
> > me. I'm not just interested in seeing TWAIN on UNIX. I think
> > there is an opportunity with SANE to create a driver development
> > 'kit' that abstracts away the physical communication with the OS,
> > rather like ASPI does, though I'd like to see something less wire
> > dependent.
> >
> > Perhaps such an abstraction already exists, if not it needs to,
> > since it would significantly reduce the effort of porting drivers from
> > one OS to another, which is the main reason you see so many
> > devices well supported on one platform and weakly supported
> > or unsupported on others.
>
> Yes. This is exectly, why sane includes the sanei_* interfacing files that
> abstract the paths to the hardware.
>
> > In this case it would then be highly desireable to see SANE
> > on Macintosh and Windows platforms, since it would reduce
> > the driver development effort.
>
> Yes. Adding an ASPI layer for SANE should IMHO be no big deal. Generic SCSI
> support is there for the Unixes in some flavours, so I assume adding in
> ASPI shouldn't be a big deal.
Let me interrupt here and suggest Java. Not nessicatly the programing
languge as Sun has defined it (though that has advantages), but something
with a simielar goal: a simple API/Programing language that can be used
to create a backend. This will run on all platforms (ideally without the
endian issues that plague Sane today).
Now a manufacture only needs to provide this driver, everything else is
(presumiably, I know that MacSane and WinSane are not stable if they
exist at all) already in Sane. Thats not to say that Sane is perfect as
it is, only that a frontend is likely to be written. For this reasons I'm
going to use Twane as the combination of twain and sane in what follows,
to indicate that even though this is like Sane, it is extended, and might
or might not be compateable with Sane.
Lets look at your typical manufacture: they do reasearch and decide that
85% (I made this number up, but it is reasonable) of their cusotmers will
run windows 98. So they write the backend, once, and distribtue that.
They also buy the rights to winSane, put their own logo on it, and change
some of the buttons so they look better with their scanner's features.
Everything else is included already, if you want network scanning, that
comes free. They basicly package the rest of Twane on a CD rom, with no
programing effort.
Now for the other cusotmers, they take the backend (which is
platform independant, so it will run on the new intel CPU that isn't
released yet) and download the Twane package for their computer from the
internet. Because the backend is platform independant there is no problem
with the manufacture not wanting to tell you how their scanner works, like
Sane faces today.
> I see more problems on the common "ad-hoc" interfaces that were
> invented, like using the parallel port, or the serial port in
> nonstandard ways. I have heard of at least one scanner that uses the
> serial port modem control lines instead of the data lines to transmit
> data.
>
> We should make up standard APIs for accessing:
>
> - the SCSI-buses of the host system
> - serial ports (used in the "normal" way).
> - parallel ports
> - USB
>
> Most other methods (homebrew interface cards and such) aren't in common use
> anymore these days.
Thank God... Twane should probably expliciatly state that other
interfaces are not supported. I'd consider dropping parallel ports and
serial ports in favor of Usb. (this probably isn't pratical yet, but a
footnote to suggest moving to USB)
This make Twane responsiable for defining other interfaces as needed. For
instance if some want a firewire interface, or fibre channel. (accually
the above two are scsi so this is a bad example, but I can't think of
anything else offhand. Maybe the apple desktop bus but that is obsolete
in Apple's eyes)
> Yes and no. SANE does have GUIs (two of the three existing SANE frontends
> are graphical), but the GUI is not tied to the scanner.
>
> It is possible to write customized GUIs that work with only one scanner
> and can be tweaked to the manufacturer's liking.
Right, and this is a strenght. We provide a reference implimentation, I
suspect that the rights to windows frontend could be bought, and all a
manufacture would do it put their logo on it, and a few other changes.
This goes a long way toward your goal of making it easier for the
programers. The GUI is the hardest part of writing a program like this,
and they can do nothing if they are willing for a reference
implimentation.
> > - TWAIN assumes the presence of a Windowing system (which
> > is pretty reasonable for Windows and Macintosh, and for a
> > lot of UNIX systems). The reason for the GUI is that it takes
> > away the burden of capability negotiation from the application
> > writer.
>
> Yes. This is what we should add to SANE in a generic manner. The existing
> frontends are capable of interfacing with the most well known photo-retuche
> software for Unix, the GIMP, but not much else.
(snip)
> So it would look like this:
>
> application -> TWAIN-API -> TWAIN_2_SANE frontend remote control interface
> -> SANE frontend -> SANE backend.
>
> This gives the best of both worlds:
>
> The application uses the simple but small and efficient TWAIN API, which is
> well known and thus no problem to implement for most programmers.
Good idea. Worth repeating.
> We write a TWAIN_2_SANE glue layer, that handles communication with the
> SANE frontend, which display the GUI, lets the user press his buttons and
> hands back image data to the application.
>
> The sane frontend communicates with its backend as usual.
>
> > This means that an app writer can communicate with a
> > Source with a minimum number of calls, without losing access
> > to all the features of the device represented by the Source.
>
> Yes. However, tying the GUI into the driver itself means, that you have to
> heavily modify the driver for each GUI. GUIs differ very much in their
> method of communicating with their client programs, what often requires
> large source code changes to accomdate different programming methods that
> are to be preferred for the different GUIs.
>
> This is why I suggest that extra layer. The GUI gets insulated in the
> SANE frontend.
>
> This allows to - for starters - write one single X11 GUI and be done with
> it. All the manufacturer really needs to deliver is the backend.
Right, no need for front ends, but you can get as complex as your
like/money allows.
> The application->TWAIN->frontend patch can be done with standard
> components.
>
> > - I'm going to say that last bit again in a different way, since it is
> > an important part of the TWAIN philosophy. When we are
> > working on the TWAIN specification, we often ask the question
> > "does this make things easier for the Source writer or for the
> > application writer?" Whenever possible we try to make things
> > easier for the application writer, since there are many apps for
> > every Source.
Yes, but by adding Sane in (or forcing all Twain programers to impliment
this part of Twain) the application programer can be lazy if they want, or
they can go through as much effort as they want. The first programers
working with a new 3-D screen would want to be elaberate in their killer
application.
> We have a somewhat different paradigm here, as compared to the number of
> available applications that want to handle scanners directly, the number of
> supported source sis rather big. However if we had a very simple API,
> like TWAIN is supposed to be, this could change.
>
> > - And having said that, let me say that TWAIN has been and is
> > continuing to emphasize the programmatic side of the interface.
> > This is because some application writers really hate those
> > internal TWAIN GUIs, and want to assume full control of the
> > Source. It's an ongoing process to convince Source writers to
> > take the time to fill out both interfaces.
>
> Yes. I see. Moving to a scheme like the one I propose above would very
> probably emphasize that need.
>
> The SANE API gives full control to the application programmer, while using
> some standard frontend we could also provide the simpler to use TWAIN API
> in one swoop.
Which is really the have your cake and eat it too that we want.
> The SANE API enforces the complex, yet detailed interface between front- and
> backend. Using a frontend you can get a simple API from it, giving you both
> sides of the coin.
>
> > As I've stated in my other mail messages today, I believe the
> > immediate win from seeing SANE and TWAIN on UNIX, Windows
> > and Macintosh platforms is that it removes an impediment from
> > application writers who want to try their hand on another platform
> > without massive code rewrites.
>
> Yes. I think this is most easily possible by separting out everything in
> which the different host OSes differ. To me that is:
>
> - hardware interfacing (handled by the sanei_* interfaces)
> - GUI (handled by the SANE frontends)
> - eventually inter-process-communication (handled by the TWAIN_2_SANE bit
> I mentioned earlier).
>
> > Of course, the cool thing about X is that it can display windows
> > across the net, so the fact that TWAIN requires a GUI does not
> > preclude the use of remote capture devices.
This works, but isn't the right way to do things. It is easier to have
Twane discover all scanners on the network from whatever machine it is
started from than log into the machine the scanner is attached to, and set
your display back. Not that it is impossibal, only that it isn't as
transparent as we would like.
I don't think Sane provides a network neighborhood type scanner brwoser,
but that would be a nice addition.
> > For the time being I recommend that we not worry about running
> > TWAIN on console mode systems. TK/TCL could be used to
> > accomodate this, but if my initial assumption is true, that the first
> > targeted developer audience is application ports, then there
> > won't be anyone interested in running TWAIN on a system that
> > isn't also running X.
Don't belive that. Unix is used for a lot more automatic work. Consider
an automatic document feeder. The user of such a thing may want to dump
20,000 checks into the machine and after finishing lunch see the numerbs
in the spreadsheets This is the ideal application for not using a gui.
(Checks are simple forms, and if you can write a working OCR [not easy]
you can batch process them) Why have a gui when the user won't even look
at it?
> > There is nothing preventing us from looking
> > into this later, if a real need is identified (I realize that some remote
> > scanning solutions might be 'very' interested in this).
Expirence with Twain seems to have taught that the optional featuers are
not implimentated. Twain does provide a way for an application to address
a scanner directly, but it isn't used in most scanners.
> > We've discussed the notion of a single, standard interface that
> > applications could invoke as an alternative to the Source's GUI
> > and to writing a complete programmatic interface. This path
> > looks nastier the longer one looks at it so we've shelved it for
> > now, but if the SANE group has ideas on this, we're more than
> > happy to dust off the issues and chat about them again...
I'm not sure why Sane hasn't solved this, when you remember that a
manufactures can customise their GUIs.
> Thus towards the GUI, we do not describe, how it should look like, but only
> what options it should offer and which possible values it can accept.
--
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