The LTSP project supports scanners, via SANE. I guess we could perhaps do the same.
I've investigated this now. I've looked at four solutions: 1) Using a scanner with built-in network support. The problem is that these kinds of scanners are very rare. I've only found one that it's supported by SANE: Dell 1600n. This is a large and expensive multi-purpose machine and it's not even sold anymore. Another major problem with this solution is that it does not provide any security, since it's communicating outside our SSH tunnel. 2) Use a network "document server", like AXIS 70U or 7000. One problem is cost: 70U currently costs 6681 SEK at Inwarehouse. Another one is operation: The idea is that you e-mail the document to predefined adresses. This is not very flexible. Also, this means that we have no encryption. 3) Use USB redirection via libusb. One problem is that Linux libusb lacks network support. Sun Ray supports scanner redirection via libusb, but they have their own "hacked" libusb. Another drawback is that the solution is tied to USB: We cannot support network scanners or interfaces like SCSI, Parallell, Firefire etc. 4) Use SANEs built-in network support. We could ship a "saned" network daemon with the TL client that dynamically links to libsane. This way, TL client would act just like a local scanner application. This principle is also used with tlclients other redirection services. It would support any kind of (preconfigured) scanner, regardless of interface etc. It would even be possible (in theory) to run export a scanner via tlclient from inside a TL session. The SANE network protocol is not without problems, however. The main issue is that is used dynamically allocated data ports, just like FTP. This does not work with our SSH tunnels. I've started looking about this problem and it does indeed look like the protocol can be modified to transfer the date inside the main TCP connection. A time estimation for implementing scanner support via SANE is: Finishing the elimination of the data port: 8h Implement support for backwards compatibility: 3h Configurable port number for the net backend: 4h Adapt tlclient to call "saned": 4h Package "saned", documentation: 8h In total, 27h, plus the 5 already spent.
Created attachment 217 [details] Half-finished patch against SANE CVS for data port elimination The patch is against SANE CVS as of 2006-10-26. It implements the new SANE_NET_START2 procedure. It also defines a skeleten for the SANE_NET_READ procedure. What remains is to implement this, in both end. This requires creating a pipe or socketpair which can be fed to the application. We need to use forking/threading to fill this pipe. Also, need to think about blocking/nonblocking. We should try to aim to make SANE_NET_READ as similiar to sane_read() as possible, though.
Interesting URL: http://blogs.sun.com/ThinkThin/entry/sun_ray_connected_scanners_in
I've submitted a tracker for this: https://alioth.debian.org/tracker/index.php?func=detail&aid=312478&group_id=30186&atid=410366
http://www.scanner-news.com/network-scanning-solutions/network-twain-scanners-is-your-driver-%E2%80%9Ctrue%E2%80%9D/ is interesting: It states that some network TWAIN drivers simply supports importing images from a folder: "The user opens their scanning application and clicks “scan”. The Network TWAIN driver opens and gives the user the option to import a document that has already been scanned. Typically these drivers assume that you have already scanned the documents by physically going to the scanner. In most cases these scanned documents get stored to a network share folder or within the scanner’s memory. We call this the “push” method because you “push” the scans to a directory and then access them later. Network TWAIN drivers that function like this are essentially a TWAIN compatible file import feature; not a “true” network TWAIN driver. This can be useful if your scanning application doesn’t have a file import feature and only allows you to scan documents in. You can also purchase 3rd party TWAIN drivers created specifically for file import as well." In the case with our "TLCOS hack" (see bug 2227), this could actually be very useful.
The TLCOS/localdrives solution is now covered by bug 3526. When implementing this bug, we should remove that solution, if we have decided to include it.
(In reply to comment #1) > I've investigated this now. I've looked at four solutions: > 3) Use USB redirection via libusb. One problem is that Linux libusb lacks > network support. Sun Ray supports scanner redirection via libusb, but they have > their own "hacked" libusb. Another drawback is that the solution is tied to USB: > We cannot support network scanners or interfaces like SCSI, Parallell, Firefire > etc. 10 years later, a few things have changed, so I now believe that the best way to handle scanners is by supporting a libusb based USB redirection. This is the de facto solution selected by IGEL, Sun Ray, and to some extent Microsoft. See bug 310.
(In reply to comment #9) > 10 years later, a few things have changed, so I now believe that the best way > to handle scanners is by supporting a libusb based USB redirection. This is the > de facto solution selected by IGEL, Sun Ray, and to some extent Microsoft. See > bug 310. Closing in favour of bug 310 and bug 6207.
