On Mon, 30 Oct 2006, m. allan noah wrote: > > You might need non-blocking with command line or cgi scripts as well. > > Nowadays, users expects "AJAX-typ" pages, that can load incrementally. The > > old style "read everything, write everything" is not fun, not even with > > CGI scripts. > > ajax is beside the point. lets just say that there are apps where non-blocking > is not required, and apps where it is. and in every case i can think of, it is > the FRONTEND that has the reason for it to be non-blocking.
Yes, it is the frontend that has the need. The question is how much backends should provide. In other words: Who will need to do the hard work: The backend or the frontend developer? I'm not surprised that backend developers wants to implement as little of the API as possible :) > > 2) Application developers needs to support backends which cannot do > > non-blocking or get_select_fd, and must therefore use threading/forking > > themself. > > correct, but _only_ if he needs it for his frontend. no-one needs to > thread/fork if the frontend does not care to. True, you have a point here. > > This seems like a lose-lose situation: Both the backend and frontend > > developers needs to handle all three cases. Well, the frontend developers > > could skip to try non-blocking and get_select_fd and *always* thread/fork > > themselves. But that would mean that the non-blocking/get_select_fd code > > in the backends are useless. So one idea is to simply make non-blocking > > sane_read and get_select_fd deprecated, and eventually remove them... > > > > my preferred solution, but i do not speak for the other devels. I think that this solution is at least better than doing nothing at all. I'm positive. > > Personally, I think the select loop model is superior, but since not all > > backends supports get_select_fd, an otherwise select based application > > might be forced to start to fork/thread. Not pretty. > > > > in general, the backend is going to have to fork/thread to give you your > select_fd. i feel that the management of such OS-specific libs, creation of > children, dealing with signals, etc. is in the frontend. You have a point. OTOH, sanei does provide this infrastructure. > > I'm not really sure of what needs to be done, but again, I believe the > > current situation is non-optimal. Right know, I tend to favourize this > > solution: > > > > 1) Deprecate sane_set_io_mode() (and thus non-blocking sane_read()). It > > doesn't give the frontend developer anything that sane_get_select_fd() > > + select() doesn't give. > > > > 2) Make sane_get_select_fd() mandatory on UNIX. > > > > The only "problem" with this solution is that the select based model > > cannot be used on Windows, but few people wants this anyway, they are > > using threads instead. > > > > i would say at this point, that the only way you would ever see that kind of > change would be as a part of the SANE2 standard. there are just too many > existing backends that would have to be changed. After looking through about 30% of the backends, I believe you are correct. Most backends does not support get_select_fd(). > the better solution, imho, is the one taken by e.g. XSANE. if your frontend > cares about non-blocking mode because its a gui or whatever, then let it deal > with the issue. this is pretty much standard fare for other libs for dns > resolves, http/ftp transfers, etc. existing SANE-1 backends can drop the code > which provides these options, and the ABI/API does not change. SANE2 can > remove the function calls, or leave them such that old frontends can be easily > ported. For DNS resolves you have ADNS. Many HTTP libs also provides non-blocking support. But, you have a point, I agree. libusb doesn't currenly provide an asynchronous interface either. Regards, -- Peter ?strand ThinLinc Chief Developer Cendio AB http://www.cendio.se Teknikringen 3 583 30 Link?ping Phone: +46-13-21 46 00 From arn...@cs.berkeley.edu Tue Oct 31 21:39:47 2006 From: arn...@cs.berkeley.edu (Gilad Arnold) Date: Tue Oct 31 22:09:49 2006 Subject: [sane-devel] UMAX Astra 2000U works with umax1220u backend driver Message-ID: <20061031203947.gc1...@mlibra.cs.berkeley.edu> Hi all, This is to let you know that I managed to install and properly scan a color image with a UMAX Astra 2000U USB scanner, using the umax1220u backend driver, on my Gentoo linux machine (kernel 2.6.16-suspend2-r8). As far as I can tell, the image was properly scanned using the xscanimage frontend GUI application, including preview and preview-based boundary definition. I would suggest that (unless contradicting evidence is known) the support level for this device can be raised above "minimal". Or, I'd be happy to conduct further tests to make sure it really works as expected. (Note that I'm not subscribed to the list, please reply to my e-mail address as well.) Regards, Gilad
