Actually, what you are suggesting is something called "Jini", also developed
by Sun, which puts the device drivers and other smarts into each device, and
they can auto-configure and communicate over a "network", maybe a SCSI bus,
or PCI bus, or ethernet...
> > > 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.
Not only isn't it transparent, but using X as a "remote access" protocol is
nearly useless in this regard. If I start a scanner interface on a remote
box, using X to display on the local monitor, so what? I still can't save
the data onto my local disk, I still can't access the data from a local
application.
There should be **NO GUI** in a device driver. What would happen if you
needed a GUI to format each different disk drive? What if there was a
differnet GUI for copying files to a floppy disk, and yet another to
read files from a CD-ROM? What you need is a generic interface to an
underlying device, with the capability to do additional device-specific
functions if required.
> > > 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.
I don't see this as useful at all. Again, even if there is X installed on
a system with a scanner, if it is remote to the user, then there is no
way to use the scanner if it requires a GUI. What if the user is on a Windows
or Mac box? Do they need to be running an X server in order to scan? The
only useful abstraction is the way SANE does it now - the backend reveals
capabilities to the frontend, and the frontend renders them locally. If a
scanner manufacturer wants enhanced functionality, they add new capabilities
to the backend and the frontend, and frontends that don't support these new
capabilites will ignore them.
The real question, as I see it, is why have TWAIN on Unix systems in the
first place? I don't think there are any TWAIN apps on Unix at the current
time, and if developers are porting over PC/Mac apps to Unix, they can
always use SANE to interface with image acquisition tools. It's actually
counter-productive to expect any kind of TWAIN support in the Unix world,
since all there is right now is SANE, so they should use what's available.
To be honest, it shouldn't be too hard to develop another TWAIN GUI
front-end on the Windows side that talks to a SANE back-end, since one
person has already done so (it didn't work 100%, but then again it only
took a week). This would allow remote scanning right away, and if scanner
manufacturers want a cross-platform standard, SANE would probably win out
over TWAIN.
Cheers, Andreas
--
Andreas Dilger University of Calgary \ "If a man ate a pound of pasta and
Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \ cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert
--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com