> I am interested in adding a TWAIN-driver-level-interface to xsane.
Good. And you are the perfect person to try it first, as you're the author
of xsane and have a very thorough understanding of SANE.
Yes. I think we should try exactly this. When we have it running with
xsane, we can add the interface to other frontends as need arises.
> > abovementioned "remote control" for SANE frontends.
> We should define a standard for the communication
> between the TWAIN to SANE-FRONTEND wrapper
> and sane frontends.
Yes. Let's give this a try:
> -- TWAIN-application layer
I think this is well defined by the TWAIN standard. AFAIK all that needs to
be done is to (dynamically) link the application to a TWAIN library and
calling into it - right ? Mark ?
> -> TWAIN-source-selection-layer
I am a little unsure here: Should we map that right through to the SANE
source selection, or rather leave that to the SANE frontend's GUI itself
and use the source selection of TWAIN to select the SANE frontend ?
The best thing would probably be to go through a configuration file that
looks a bit like that:
# TWAIN_2_SANE bridge configuration
#
# Available sources:
#
# Show all devices that xsane sees
xsane:*
# Show only a single device for the vendor-GUI, which only works right
# with the vendor4711 scanner anyway:
vendorGUI:vendor4711
We could as well add in sections that select by the asking program, thus
e.g. giving the GUI that fits best with the look and feel of the requesting
program.
Other than that, I'd say we just implement that as part of the TWAIN library
that gets linked to the application.
> -> TWAIN to SANE-FRONTEND-wrapper
That is the hard part, especially, if we try to:
> The wrapper and the standard has to be compatible to
> all operating systems.
On Unix I would use some form of IPC. Probably pipes. How is it handled on
Win and MacOS now ?
I.e. is the scanner GUI run as dynamically linked "subroutine" of the main
program or is a separate program started to display the GUI and communicate
with the TWAIN library ?
Using the cygwin tools, it should be definitely possible to use the separate
program+IPC approach on windows, but I do not know about the Mac.
The advantages of the separate process approach are:
- The SANE frontends need only minimal modification, and they still run
standalone.
- The frontend and backend can use separate GUI-toolkits without pushing
the memory requirements for the main application up further. Total memory
requirement is the same of course, but often application memory space is
limited on a per application basis.
- Security is enhanced, as the frontends run in a separate memory space.
This means:
a) a faulty frontend cannot take down the application. I have seen too many
badly written GUI-frontends from vendors that could be taken down by
pressing the wrong combination of options. I think most users would
be grateful, if the graphics program with the many unsaved changes would
continue running, even if the frontend crashed.
b) the frontend can be given extra permissions like being "sgid-scanner"
giving it access to the SCSI devices. I know, that security is not much of
an issue on the average Win box, but for Unix, you will not get a foot on
the ground, if security is not maintained.
The disadvantage is having to use IPC instead of direct procedure calls.
And IPC is strongly system dependent. I think no system would have a problem
with spawning an extra process, as this is a common thing used for calling
up a help browser or similar. So the question is about IPC.
As long as we have a posixish environment, we should have pipes, which
should suffice for that task.
But actually, as both the TWAIN library and the frontends will depend on the
Host OS (the former due to the way they need to be linked, which is a minor
issue, but the latter due to the GUI), this is not so big an issue, as we
can define an ideal method of communications for each platform separately.
The more we can unify, the better, though.
I think pipes are probably best for starters, as they enforce a streamed
protocol, that can definitely be used on any platform of interest, at worst
using a TCP/IP connection to localhost, which every platform that is in use
nowadays should support.
CU, Andy
-- = Andreas Beck | Email : <andreas.beck@ggi-project.org> =
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com