[sane-devel] Good bye
Hello friends, sane-developpers, sane-users and everyone else who may be interested. I have been active for more than ten years for SANE and on the sane-devel mailing list now. In the last years my priorities have changed and so I decided to spend my time for my family and my little doughter in the future. I will still spend a little time for the development of XSane, but I decided to unsubscribe from the sane-devel mailing list now. I hope my work has moved SANE a bit into the right direction. But I realized that I am the wrong one to give SANE the needed power to make the next step. I tried to make the jump to SANE2 about five, six or more years ago. But when there is no one who wants to follow a new standard then it does not help to develop or optimize the new standard. So it seems the right time for me to leave SANE now and make place for others. For the future of the SANE standard I hope that you will take the right decisions and that you will find a lot of people that are willing to spend their time to add SANE-support for new scanner devices and the new standard. I hope that you will find a (new) leader for SANE. In fact we had no active leader for the last years, and I think this was really bad. I hope you will find someone like David Mosberger about 12-13 (?) years ago, someone who is spending 200% of his free time to move SANE, someone who has a target for SANE, someone who cares about everything but also is able to make decisions. This is my last mail on sane-devel. So I say good luck and good bye. Best regards Oliver
[sane-devel] never run into sane_get_devices! why?
Hi, All When I debug a backend with xsane, only the sane_init of the backend can be called, but It never runs into the sane_get_devices. (I make sure the sane_init returns SANE_STATUS_GOOD) What may cause to this problem, I have think much about this, help please. Thank you! -- Do what I can do, not only what should I do. -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080401/fda487b1/attachment.htm
[sane-devel] Developing SANE driver------A strange issue
see sane standard section 4.1- this is protection against incompatible frontends and backends trying to communicate. allan On 4/1/08, windflying zhou windflying.zhou at gmail.com wrote: Hi, All Can you tell me why can only run into the sane_get_devices() unless you use *version = SANE_CODE_VERSION(1, 2, 3) in the sane_init(). If not, you will never run into sane_get_devices() with libsane. WHY! WHY! Thank you! -- Do what I can do, not only what should I do. -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org -- The truth is an offense, but not a sin
[sane-devel] SANE2 standard completion
Hello, On Mar 28 18:40 Julien BLACHE wrote (shortened): ... I think it'd really be better to have the frontends be entirely isolated from the backends, as I explained already. This would provide a central point (saned) handling the hardware entirely To avoid confusion with the cupsd, I like to mention that the cupsd does not talk to the hardware (i.e. the printer). In CUPS there are so called backends which talk to the final destination of a print job (usually the printer but often also a network service like IPP, LDP, or SMB), see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell Furthermore I like to mention that the HP printer and scanner driver HPLIP had in the past such a kind of daemon hpiod which did the actual hardware I/O. There have been several drawbacks with such a daemon so that HPLIP dropped the daemon and uses now a library libhpmud which does the actual hardware I/O. I.e. perhaps in the end a library is better than a daemon? Perhaps the crucial question is not whether the hardware I/O is done via a library or via a daemon but to get the frontends be entirely isolated from the backends regardless if this is implemented via a daemon or via an additional I/O-library? I think when a driver for all-in-one devices moved from a daemon to a library, it might indicate that this is also true for plain scanner drivers? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
[sane-devel] SANE2, what do we want ?
Hello, On Mar 28 22:49 Julien BLACHE wrote: Till Kamppeter till.kamppeter at gmail.com wrote: ago and no one answered). This will help us that it is much easier for scanner manufacturers to ship drivers with their scanners. They can This is all but a good thing. Currently, binary backends provided by the manufacturers are nothing more than a total annoyance. They're crappy, non-debuggable, under-documented, badly written, badly tested, and available for Linux/i386 only. Encouraging binary backends undermines the efforts done by backends developers over the past years to obtain specification/documentation from the manufacturers. Think twice, please. You're actually actively harming both SANE and the users by doing so. Could you please avoid such harsh wording and be gentle and assume that those who post something are no idiots. What have broken binary drivers to do with a LSB standard? Did Till write that the LSB standard applies only for broken binary drivers? For example the hpaio driver from HPLIP is free software. For example the epkowa driver from IScan is free software. I would appreciate it if there were more free drivers from manufacturers but manufacturers ask for reliable standards. If SANE1 was LSB, there would be such a reliable standard. If SANE1 was LSB, it would not mean that there cannot be SANE2 but it would mean that a nice migration path from SANE1 to SANE2 would have to exist or that SANE2 is backward compatible to SANE1 (software for SANE1 would have to work in a SANE2 environment). Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
[sane-devel] SANE2 standard completion
Hello, On Mar 28 19:13 Julien BLACHE wrote (shortened): ... provide a central point (saned) handling the hardware entirely, ... Something much more simple than CUPS, but yeah, basically. ... Oh, I forgot to add: we get real locking/device management that way, too. It may get complicated for all-in-one devices when both the CUPS backend and the saned try to communicate at the same time with the device. The CUPS backend runs only as long as one particular print job is sent to the device, then it finishes. To make printing possible, the saned should release a locked device file when it is not actually in use. But how to deal with a user who runs a frontend to scan multiple sheets on a all-in-one device and in between a (longer) print job comes (e.g. from a remote machine)? Should the frontend tell the saned to keep the lock until the last sheet is scanned (i.e. provide something like a [Lock]/[Unlock] button in the frontend) or might the print job hinder the user to continue scanning? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
[sane-devel] SANE2 standard completion
Johannes Meixner jsmeix at suse.de wrote: Hi, The CUPS backend runs only as long as one particular print job is sent to the device, then it finishes. Same for saned. But how to deal with a user who runs a frontend to scan multiple sheets on a all-in-one device and in between a (longer) print job comes (e.g. from a remote machine)? Exactly the same situation we have today. The locking I am talking about is only between SANE clients, in the sense that it would be possible to tell a user Sorry, this scanner is already in use instead of whatever non-obvious message you get today. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] SANE2 standard completion
Message du 01/04/08 15:03 De : Johannes Meixner jsmeix at suse.de A : sane-devel at lists.alioth.debian.org Copie ? : Objet : Re: [sane-devel] SANE2 standard completion Hello, On Mar 28 18:40 Julien BLACHE wrote (shortened): ... I think it'd really be better to have the frontends be entirely isolated from the backends, as I explained already. This would provide a central point (saned) handling the hardware entirely To avoid confusion with the cupsd, I like to mention that the cupsd does not talk to the hardware (i.e. the printer). In CUPS there are so called backends which talk to the final destination of a print job (usually the printer but often also a network service like IPP, LDP, or SMB), see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell Furthermore I like to mention that the HP printer and scanner driver HPLIP had in the past such a kind of daemon hpiod which did the actual hardware I/O. There have been several drawbacks with such a daemon so that HPLIP dropped the daemon and uses now a library libhpmud which does the actual hardware I/O. I.e. perhaps in the end a library is better than a daemon? Perhaps the crucial question is not whether the hardware I/O is done via a library or via a daemon but to get the frontends be entirely isolated from the backends regardless if this is implemented via a daemon or via an additional I/O-library? I think when a driver for all-in-one devices moved from a daemon to a library, it might indicate that this is also true for plain scanner drivers? That's the point: CUPSD is a daemon regardless of implementation of the backend, daemon or I/O-lib. Nothing talk or invoke directly this io backend all talk to CUPSD via tcp or domain-unix socket in case of printing. It should be the case too for scanning via saned. io-backends should be internal API like in cups today. Sharing problem of multifunction device is another independent one and is already a problem today without saned. It is linked to the capability of the device (not all could do print and scan at the same time) and could be cleanly addressed and hidden in the io-backend/driver with perhaps a little bit help from the saned/cupsd side and without breaking or touching the sane client side. Clean, simple, backward compatible and evolutive front end and backend isolation is way way simple to achieve and to maintain via a client/server based isolation than a library based isolation. And about daemon bloat: saned job would be very simple in comparison with a complete network spooling and document printing processing system like CUPS. Cheers, Emmanuel. Cr?ez votre adresse ?lectronique pr?nom.nom at laposte.net 1 Go d'espace de stockage, anti-spam et anti-virus int?gr?s. -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080401/e3450454/attachment.htm
[sane-devel] SANE2, what do we want ?
On 4/1/08, Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: Julien BLACHE jb at jblache.org writes: Johannes Meixner jsmeix at suse.de wrote: For example the epkowa driver from IScan is free software. No, epkowa is not free software. A large part of the scanners it supports actually rely on proprietary, binary-only protocol interpreters shipped as Linux/i386 shared libraries. The epkowa backend is free-as-in-freedom software. It is licensed under the terms of the GPL and carries an exception that allows for the use of non-free extensions. well, i just heard RMS speak again a few days ago, and i can tell you for sure that this exception means the backend is decidedly NOT free-as-in-freedom. we could take it up with him if you like... allan -- The truth is an offense, but not a sin
[sane-devel] SANE2 standard completion
Hi, Now tell me, how do you transparently share scanners from one box to another without a daemon? I never said that. I said ? how to avoid running service if there is no scanner plugged ? ?. I even implemented a daemon for polling sensor. Please reread past mail rather than putting words in my mouth. ?tienne.
