> > I think we should have a look how TWAIN does this on windows/mac. Of
> > course using pipes is the simplest way to do it, but as far as I know
> > there are no pipes on Windows and Mac.
> Direct function calls.
Though the interface is through a single function with a protocol that
is very "streamlike".
> And by the way, I do *not* want to go sending 300DPI color images around
> through pipes.
If you are using SANE, you probably do so already. Most backends are
implemented to spawn off a reader process, which communicates with the
main (control) process via a pipe. The same applies again, when you use the
source from GIMP as a plugin, giving two pipes between the source and the
application, plus an "effective" on at the backend->scsi interface.
I do not see a performance or other problem with that. Maybe for video
capturing, but not even for very fast scanners. As long as the hardware-bus
the scanner is attached to, can carry it, I see no problem for a loopback
device like a pipe to carry it.
Doing direct function calls means having the frontend in the application
memory space. And if we don't go through netsane, it means having to give
special priviledges to the application, as the backend is then also in the
application memory space and it needs to open the hardware path to the
device.
_I_ will not do that. I do trust a small and opensource piece of software
like a SANE frontend and the corresponding backend. But I do not feel like
trusting every funny binary-only application that happens to want to use
TWAIN.
It isn't a question of assuming dragons everywhere, it's a question of
maintaining stability. The more complex the application, the more likely
it has a bug.
This is the reason, why Unix people keep the size of security critical tools
small. You can have a nice graphical frontend to passwd, but what it usually
does, is to run at reduced priviledge and spawn the simple textmode passwd
program as required.
Thus I do think, that running everything in one memory space is a bad idea
for security conscious OSes and users, and that there should be at least
one separation between the application and talking to the hardware.
O.K. - I can use the netsane interface to shield me, but that's a pretty
awkward way I'd say.
If pipes turn out to be too slow for some applications, we can talk about
alternate transports (shmem for example). If the transport layer is well
encapsulated, that should be trivial to change.
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