[sane-devel] Sane Release 1.1.0 ?
Hello, On Nov 8 10:06 stef wrote (shortened): as a proof of concept, I have made 2 different versions of SANE coexisting on my system. ... I have created a meta backend which is a copy of dll.c, but that searches only backends with a major of 1 and has no preloaded backends. I added the meta backend to dll.conf. Very many thanks for this real test! Regardless what the final result will be, the only thing which is of real importance for us (i.e. for the openSUSE distribution) is that different SANE versions work o.k. out of the box. work o.k. out of the box means on the one hand no loss of supported models (i.e. no regression bugs) but on the other hand it menas that it can happily crash when the user did special manual changes. For example we use a backend only via a dll meta backend (and I assume the other distribution do it too - i.e. no backend is directly linked with a frontend) so that you can add as many meta-backends as you like as long as this works o.k. out of the box. Out of the box means also that it would be no problem for us, to provide an updated SANE 1 sane-backends package together with a new SANE 2 sane2-backends package if changes in the SANE 1 sane-backends package are required so that this one can coexist with the SANE 2 sane2-backends package. This is no problem for us because we provide the whole box i.e. we can easily provide an updated SANE 1 sane-backends package in the next openSUSE version if it is needed. This would also work for an update from one openSUSE version to the next openSUSE version because the installed packages (i.e. the installed sane-backends) would be updated too. If I understand you correctly, the dll meta backend is the one of the newest SANE version. Assume now there is SANE version 1, 2, and 3 which should coexist on one system: Then the dll meta backend is of version 3 which loads only backends which are compatible with version 3 (i.e. in its dll.conf there are only backends listed which are compatible with version 3). For backward compatibility with version 2, there is a dll2 meta-meta backend which is compatible with version 3 (i.e. listed in dll.conf) but this one loads only backends which are not compatible with version 3 but which are compatible with version 2 (i.e. in its dll2.conf there are only backends listed which are compatible with version 2). For backward compatibility with version 1, there is either a dll1 meta-meta backend which is compatible with version 3 (i.e. listed in dll.conf) but this one loads only backends which are neither compatible with version 3 or version 2 but which are compatible with version 1 (i.e. in its dll1.conf there are only backends which are compatible with version 1) or a dll1 meta-meta-meta backend which is compatible with version 2 (i.e. listed in dll2.conf) but this one loads only backends which are not compatible with 2 but which are compatible with version 1 (i.e. in its dll1.conf there are only backends which are compatible with version 1) Currently I do not fully understand all implications of it but it seems that this naming scheme could be a drawback because currently the dll meta backend is of version 1. Why not keep the old name dll for the meta backend for version 1 and use new names (i.e. dll2 and dll3) for the higher versions? Or is it better to overwrite an existing SANE version 1 dll by the new dll and add dll2 for backward compatibility? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
[sane-devel] Sane Release 1.1.0 ?
Le Tuesday 11 November 2008 10:38:48 Johannes Meixner, vous avez ?crit?: Hello, On Nov 8 10:06 stef wrote (shortened): as a proof of concept, I have made 2 different versions of SANE coexisting on my system. ... I have created a meta backend which is a copy of dll.c, but that searches only backends with a major of 1 and has no preloaded backends. I added the meta backend to dll.conf. Very many thanks for this real test! Regardless what the final result will be, the only thing which is of real importance for us (i.e. for the openSUSE distribution) is that different SANE versions work o.k. out of the box. work o.k. out of the box means on the one hand no loss of supported models (i.e. no regression bugs) but on the other hand it menas that it can happily crash when the user did special manual changes. For example we use a backend only via a dll meta backend (and I assume the other distribution do it too - i.e. no backend is directly linked with a frontend) so that you can add as many meta-backends as you like as long as this works o.k. out of the box. Out of the box means also that it would be no problem for us, to provide an updated SANE 1 sane-backends package together with a new SANE 2 sane2-backends package if changes in the SANE 1 sane-backends package are required so that this one can coexist with the SANE 2 sane2-backends package. This is no problem for us because we provide the whole box i.e. we can easily provide an updated SANE 1 sane-backends package in the next openSUSE version if it is needed. This would also work for an update from one openSUSE version to the next openSUSE version because the installed packages (i.e. the installed sane-backends) would be updated too. If I understand you correctly, the dll meta backend is the one of the newest SANE version. Assume now there is SANE version 1, 2, and 3 which should coexist on one system: Then the dll meta backend is of version 3 which loads only backends which are compatible with version 3 (i.e. in its dll.conf there are only backends listed which are compatible with version 3). For backward compatibility with version 2, there is a dll2 meta-meta backend which is compatible with version 3 (i.e. listed in dll.conf) but this one loads only backends which are not compatible with version 3 but which are compatible with version 2 (i.e. in its dll2.conf there are only backends listed which are compatible with version 2). For backward compatibility with version 1, there is either a dll1 meta-meta backend which is compatible with version 3 (i.e. listed in dll.conf) but this one loads only backends which are neither compatible with version 3 or version 2 but which are compatible with version 1 (i.e. in its dll1.conf there are only backends which are compatible with version 1) or a dll1 meta-meta-meta backend which is compatible with version 2 (i.e. listed in dll2.conf) but this one loads only backends which are not compatible with 2 but which are compatible with version 1 (i.e. in its dll1.conf there are only backends which are compatible with version 1) Currently I do not fully understand all implications of it but it seems that this naming scheme could be a drawback because currently the dll meta backend is of version 1. Why not keep the old name dll for the meta backend for version 1 and use new names (i.e. dll2 and dll3) for the higher versions? Or is it better to overwrite an existing SANE version 1 dll by the new dll and add dll2 for backward compatibility? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex Hello, I fact I haven't touch dll.c at all. I have copied it under a new name 'sane1.c' and did minor changes to this file to be a 'sane1' meta backend. I have then added it to my system dll.conf which looks like: net genesys lexmark v4l rts8891 pnm smfp epkowa sane1 There is no more change than adding this compatibility meta backend. I have currently xsane linked to libsane.so.1 and xscanimage linked to libsane.so.2. libsane.so points to libsane.so.2. When I run xsane, it detects pnm:0, pnm:1 and v4l:/dev/video0 . When I run xscanimage it detects these sane1 backends as sane1:pnm:0, sane1:pnm:1 and sane1:v4l:/dev/video0 . scanimage -L reports: device `sane1:pnm:0' is a Noname PNM file reader virtual device device `sane1:pnm:1' is a Noname PNM file reader virtual device device `sane1:v4l:/dev/video0' is a Noname USB 2.0 Camera virtual device device `v4l:/dev/video0' is a Noname USB 2.0 Camera virtual device The SANE 2 package I installed hasn't the pnm backend enabled. The probe log with SANE_DEBUG_DLL and SANE_DEBUG_SANE1 set is attached. You'll notice that it tries to load the smfp and epkowa backends. The epkowa was compiled with SANE 2 installed on the system. Such construct allow for SANE 2
[sane-devel] Sane Release 1.1.0 ?
Le Thursday 06 November 2008 21:43:26 stef, vous avez ?crit?: Le Thursday 06 November 2008 11:01:40 Julien BLACHE, vous avez ?crit?: stef stef.dev at free.fr wrote: to define a way both version can coexist we have to knowwhat are the cases which lead to this coexistence on a system. In my -possibly simplistic- view, since any out of tree backend only needs a mere recompile to get in sync, I don't see at first where is the problem. Could you tell me the precise cases you are thinking of ? samsung MFP backend. No sources. No maintainer. No hope for an update anytime soon. Shitload of users. Hello, this is the kind of headache binary only drivers provide. I have a GeForce Ti 4200 that I can't use yet on a recent kernel However, do you think we could manage to get such backends still working by: - installing sane 2 backends in a different directory (dll2.d ?) where sane 1 never search for backends - modify dll.c to search in sane1 directories when given a SANE 1 major, and sane 2 directories for SANE 2 major, possibly falling back to sane 1 directories if no backend is found. Regards, Stef Hello, as a proof of concept, I have made 2 different versions of SANE coexisting on my system. First I have installed version 1.0.19 (with the pnm backend enabled) with the corresponding xsane. Then i raised the V_MAJOR and SANE_CURRENT_MAJOR to 2, compiled and installed it (without the pnm backend). I have then modified xscanimage to build against this new version and installed it. In my backend development environment, I have created a meta backend which is a copy of dll.c, but that searches only backends with a major of 1 and has no preloaded backends. I added the meta backend to dll.conf. In such a setting, xsane is using SANE 1 backends without any troubles, and xscanimage uses SANE2 backends. Furthermore, thanks to the compatibility meta backend, xscanimage can still use the SANE1 backends installed on the system (in my case I tested it with the pnm backend). The only thing left is to make SANE install its files under a sane2 subdirectory within sane.d so there is no clash on the conf files of both versions. But this is an easy thing to do. This way, we could provide support for mixed environments and keep SANE 1 only backends working. Various packages could upgrade at their own pace, and no scanner support would be lost. Regards, Stef
[sane-devel] Sane Release 1.1.0 ?
stef stef.dev at free.fr writes: Le Thursday 06 November 2008 03:14:28 Olaf Meeuwissen, vous avez ?crit?: ... They can't use these version 2 backends if they're stuck with a version 1 frontend. Hence the need for support for a scenario where you have both version 1 and version 2 backends installed. to define a way both version can coexist we have to knowwhat are the cases which lead to this coexistence on a system. In my -possibly simplistic- view, since any out of tree backend only needs a mere recompile to get in sync, I don't see at first where is the problem. Could you tell me the precise cases you are thinking of ? Put yourself in Julien's Debian maintainer shoes. Debian's lenny lists 15 packages that depend on libsane and 1 (OpenOffice.org) that suggests it. This only covers packages in main. These packages come from 11 different projects, 12 if you consider sane-frontends and sane-backends different projects, and are available for at least 4 different architectures. These are all free software, so getting them all fixed (upstream) in time for the next release is, eh well, an unenviable job. You want to volunteer? Do you also want to volunteer for all those other distributions out there? Even just the major 10 or so? Next, consider what you would need to do to get an out of tree non-free backend in sync. Repeat the exercise for non-free frontends. The chances that all the pieces are in place before anyone's particular deadline are probably less than winning the lottery. This means that at any given time for the foreseeable future, people will have to deal with frontends and backends of both versions. Hope this paints a picture, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
[sane-devel] Sane Release 1.1.0 ?
m. allan noah kitno455 at gmail.com writes: On Wed, Nov 5, 2008 at 8:42 AM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: Sanity is not the problem. The extreme need to make a release, coupled with limited developer resources is the problem. Lets bump the version everywhere to 2. Sanity and consistency of the API and its behaviour is the problem. we are making only modest changes to the API. It's behaviour is MORE consistent with the current code than with your suggestion. And I just can't believe you're pushing a release because we need to release and breaking things along the way. This is YOUR opinion. I think adding additional statuses to SANE_Status is perfect, and protecting them with version bump follows the standard to the letter. Julien is not the only one with that opinion. I for one don't care for a release that was pushed out of the door for the benefit of a mere three backends that want/need the additions and in the mean time break things along the way for all frontends and external backends. - what other reasons are there to release in such a rush? - how do you support mixed (API/so)version installations? - will a version 2 dll backend still load version 1 backends? - can version 2 frontends use version 1 backends? - will version 1 frontends do the right thing with all version 2 backends? - can everyone find the right match of versions? The mixed version installations is something that distribution will care about. A lot. Any distribution people hanging around that want to chime in here? Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
[sane-devel] Sane Release 1.1.0 ?
m. allan noah kitno455 at gmail.com writes: On Wed, Nov 5, 2008 at 6:44 PM, Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: m. allan noah kitno455 at gmail.com writes: On Wed, Nov 5, 2008 at 8:42 AM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: Sanity is not the problem. The extreme need to make a release, coupled with limited developer resources is the problem. Lets bump the version everywhere to 2. Sanity and consistency of the API and its behaviour is the problem. we are making only modest changes to the API. It's behaviour is MORE consistent with the current code than with your suggestion. And I just can't believe you're pushing a release because we need to release and breaking things along the way. This is YOUR opinion. I think adding additional statuses to SANE_Status is perfect, and protecting them with version bump follows the standard to the letter. Julien is not the only one with that opinion. I for one don't care for a release that was pushed out of the door for the benefit of a mere three backends that want/need the additions and in the mean time break things along the way for all frontends and external backends. - what other reasons are there to release in such a rush? a rush? it will be 9 months since last release if we were to start the process today, and i never suggested that. i never even gave a timeline. OK, I'll rephrase that question then: - what other reasons are there that lead to an extreme need to make a release? - how do you support mixed (API/so)version installations? - will a version 2 dll backend still load version 1 backends? It should be able to, since old backends are forward compatible If you bump the soversion someone will need to fix the dll backend or otherwise it won't. - can version 2 frontends use version 1 backends? unless the dll backend is going to change the version number, they will have to, because of external backends. Are you talking about the dll backend advertising version 1 backends as version 2 backends to the frontends here? Also note that the SANE API specification explicitly mentions the possibility of switching backends. Please don't make the mistake of assuming everyone everywhere will be using the dll backend as their frontend's backend of choice. Not saying you do, just pointing out the possibility. - will version 1 frontends do the right thing with all version 2 backends? no, that is why there is a soversion bump. we HAVE to have some mechanism to make incompatible changes to the API. ACK on the soversion bump but keep in mind that you need to support setups with *both* soversion 1 and soversion 2 backends installed. You suggested changing the version number to 2 everywhere. That would include the sane-backends and sane-frontends package versions and the SANE Standard version (and SANE_CURRENT_MAJOR). I hope I didn't miss any versions anywhere. As Julien already pointed out, changing the Standard version for the changes we have now is a really bad joke. If we can't even do something as simple as adding a SANE_Status value without a major standard version increase, something's gotta be wrong with the way we handle versioning. - can everyone find the right match of versions? most folks use the free backends we ship, and they will all be version 2. They can't use these version 2 backends if they're stuck with a version 1 frontend. Hence the need for support for a scenario where you have both version 1 and version 2 backends installed. External backends that stay at v1 should still work. there is nothing in the standard that precludes a frontend from supporting two versions, or the dll backend could change the version as it passes by, and still be accurate, since a v1 backend works just like a v2 backend, but does not use the new statuses or frame types. A soversion 2 dll backend could bump the SANE_CURRENT_MAJOR of soversion 1 backends on the fly (assuming the dll backend actually loads them) but that seems to make the whole point of SANE_CURRENT_MAJOR a bit meaningless ... I am open to suggestions on all these points. That is why I am pushing the issue, to get some ideas, and some help. I'd like to help but resources are scarce. CVS is also a show stopper (corporate firewall is getting in the way, SVN would work). Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
[sane-devel] Sane Release 1.1.0 ?
Le Thursday 06 November 2008 03:14:28 Olaf Meeuwissen, vous avez ?crit?: ... They can't use these version 2 backends if they're stuck with a version 1 frontend. Hence the need for support for a scenario where you have both version 1 and version 2 backends installed. Hello, to define a way both version can coexist we have to knowwhat are the cases which lead to this coexistence on a system. In my -possibly simplistic- view, since any out of tree backend only needs a mere recompile to get in sync, I don't see at first where is the problem. Could you tell me the precise cases you are thinking of ? Regards, Stef
[sane-devel] Sane Release 1.1.0 ?
Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: Hi, The mixed version installations is something that distribution will care about. A lot. Any distribution people hanging around that want to chime in here? /me raises both hands Oh, wait. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
stef stef.dev at free.fr wrote: to define a way both version can coexist we have to knowwhat are the cases which lead to this coexistence on a system. In my -possibly simplistic- view, since any out of tree backend only needs a mere recompile to get in sync, I don't see at first where is the problem. Could you tell me the precise cases you are thinking of ? samsung MFP backend. No sources. No maintainer. No hope for an update anytime soon. Shitload of users. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
On Thu, Nov 6, 2008 at 5:01 AM, Julien BLACHE jb at jblache.org wrote: stef stef.dev at free.fr wrote: to define a way both version can coexist we have to knowwhat are the cases which lead to this coexistence on a system. In my -possibly simplistic- view, since any out of tree backend only needs a mere recompile to get in sync, I don't see at first where is the problem. Could you tell me the precise cases you are thinking of ? samsung MFP backend. No sources. No maintainer. No hope for an update anytime soon. Shitload of users. what do its soname symlinks look like? allan -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
m. allan noah kitno455 at gmail.com wrote: samsung MFP backend. No sources. No maintainer. No hope for an update anytime soon. Shitload of users. what do its soname symlinks look like? :/usr/lib/sane% ls *mfp* libsane-smfp.so.1 libsane-smfp.so.1.0.1 JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
On Thu, Nov 6, 2008 at 9:01 AM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: Hi, but no plain .so symlink? Let me check the installer. I installed this one by cracking the installer open, binary-patching the backend so it won't segfault if not run by root and deploying the files by hand. Yeah, there is a plain .so symlink. ok, so if dll backend just tries to open [backendname].so, and ignores all the version numbers, this backend will still work, at least as badly as it ever did :) allan -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
m. allan noah kitno455 at gmail.com wrote: ok, so if dll backend just tries to open [backendname].so, and ignores Uh. Don't do that. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
On Thu, Nov 6, 2008 at 10:16 AM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: ok, so if dll backend just tries to open [backendname].so, and ignores Uh. Don't do that. What is the point of the plain .so name if you can't use it? allan -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
m. allan noah kitno455 at gmail.com wrote: What is the point of the plain .so name if you can't use it? Linking against a specific backend, loading a specific backend from the frontend directly, etc. And what's the point in having versionned backends if you discard the version? Make the dll backend load v2 and v1 backends if you want. You also have to handle duplicates, whether you use versioning or not. Really, back out the warming up change and do it the proper way instead of breaking everything and making things even more complicated for no good reason. It seems you haven't discovered half of the issues yet, which is very worrying from where I stand. The cost of this transition is way higher than the cost of doing the changes in the proper way, and if you look at what you gain ... nothing. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
On Thu, Nov 6, 2008 at 10:35 AM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: What is the point of the plain .so name if you can't use it? Linking against a specific backend, loading a specific backend from the frontend directly, etc. And what's the point in having versionned backends if you discard the version? we are not discarding the version, we are trying to find a way for v1 backends to coexist with v2 backends. Make the dll backend load v2 and v1 backends if you want. You also have to handle duplicates, whether you use versioning or not. Really, back out the warming up change and do it the proper way instead of breaking everything and making things even more complicated for no good reason. It seems you haven't discovered half of the issues yet, which is very worrying from where I stand. Please, describe for us how adding a new function to v2 backends is going to make it easier for v1 and v2 backends to be installed at the same time. allan -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
Sorry for jumping into the discussion but why don't we use sane_get_option_descriptor() / sane_control_option() on a new predefined option, for example, sane-version-features, which could be read by a frontend and if, no error occured, set to required SANE API level (aka. additional features available), specific bitmask etc. Doing that we could avoid any changes in already used API. And when such an option is set by a frontend, backends could start using additional SANE_Status. The implementation of such a solutions is rather simple. Just my .2 cents. -- Ilia Sotnikov
[sane-devel] Sane Release 1.1.0 ?
m. allan noah kitno455 at gmail.com wrote: Please, describe for us how adding a new function to v2 backends is going to make it easier for v1 and v2 backends to be installed at the same time. Tweaks to dll are needed in both cases. Except in your case you're again trying to take an easy route that will only end with more problems. I'm tired arguing, really. If you want to break everything, then fine, go ahead and we'll see how that goes. Now if you pause for a minute or two and review that carefully, you'll see it's wrong. There's no problem with being wrong, there's only a problem if you can't accept that and fix it. Sorry if that seems blunt. Both you and Stef primarily care about your backends, it seems. You do give some consideration around that and Stef very clearly doesn't. But both of you are ignoring the SANE ecosystem, not taking it into account and not even trying to see how the changes propagate into that ecosystem, with problems, side-effects and all for users, third-parties, distributors, etc. I clearly see the amount of work that will be involved to deal with this crappy warming up change, and I don't want to go there. It's just not worth it to spend that amount of time for a very, very little gain. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
On Thu, Nov 6, 2008 at 11:12 AM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: Please, describe for us how adding a new function to v2 backends is going to make it easier for v1 and v2 backends to be installed at the same time. Tweaks to dll are needed in both cases. Except in your case you're again trying to take an easy route that will only end with more problems. Julien, I'm not trying to have an argument. I am trying to get input from the ecosystem, by having this brainstorming session in public. Please, dont tell me again to stop and think about it from your perspective, HELP me think about it from your perspective, because I am not you! We all seem to be in agreement that the addition of new status and frame types is an incompatible change to the API/ABI. The standard says: The SANE standard is expected to evolve over time. Whenever a change to the SANE standard is made that may render an existing frontend or backend incompatible with the new standard, the major version number must be increased. Thus, any frontend/backend pair is compatible provided the major version number of the SANE standard they implement is the same. A frontend may implement backwards compatiblity by allowing major numbers that are smaller than the expected major number (provided the frontend really can cope with the older version). In contrast, a backend always provides support for one and only one version of the standard. If a speci?c application does require that two different versions of the same backend are accessible at the same time, it is possible to do so by installing the two versions under different names. My biggest concerns are those raised by Olaf- how do the two versions coexist. I will bet you that the solution we come up with will be EXACTLY the same, whether we add your new function or not. So, i want to leave the sane_status question aside for just a moment, and discuss these big-picture issues. How do we structure our package such that sane 1.0.19 could be installed at the same time as the new sane, along with external backends of either version? allan -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
On Thu, Nov 6, 2008 at 11:09 AM, Ilia Sotnikov hostcc at gmail.com wrote: Sorry for jumping into the discussion but why don't we use sane_get_option_descriptor() / sane_control_option() on a new predefined option, for example, sane-version-features, which could be read by a frontend and if, no error occured, set to required SANE API level (aka. additional features available), specific bitmask etc. Doing that we could avoid any changes in already used API. And when such an option is set by a frontend, backends could start using additional SANE_Status. The implementation of such a solutions is rather simple. I worry that a simple sane1 front-end might expose that option to the user, who might set it, then the front-end blows up anyway? But, there might be a way to set the caps on the option to hide it, and yet, still let the front-end change it? allan -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
m. allan noah kitno455 at gmail.com wrote: Hi, My biggest concerns are those raised by Olaf- how do the two versions coexist. I will bet you that the solution we come up with will be EXACTLY the same, whether we add your new function or not. So, i want No, if we go and add an optional status function, this problem does not exist. I covered that in my mail. If we go that route and do a 1.1, the dll backend can load *.so.1* and be done with it. If it's a 1.1 backend, it will have the function defined, nothing more to do, if it's a 1.0 backend it won't have it and dll wires up a stub instead. All backends in 1.1 define the function, a stub is used for all the backends that are unmaintained today. There, done, no problem. Total backward compatibility with anything built against 1.0. No change in the behaviour of the current API calls. Some work to do on saned/net as the new call needs to added and the version check needs to be extended a bit (1.1 client cannot talk to a 1.0 saned or needs to wire up a stub call for the new call). No big issue, takes time and testing. Plus: new status function frontends can use at any time (though the function can reply sorry can't tell you now), and in 2.0 we can separate API status (SANE_Retval or something) and hardware status (SANE_Status or something else). Now, speaking of a proper 2.0 release, this has all been discussed already. I think the best thing we came up with was a sane1 compat backend based on dll that does the conversion and stuff. That and installing the backends under /usr/lib/sane2 (avoids dupes - note that you can restrict dll to *.so.2* and sane1 to *.so.1* instead). Some work on saned/net required as usual, version check needs some work and testing to ensure saned and the client reject the other version as needed. Makes no sense for such small changes. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
On Thu, Nov 6, 2008 at 12:13 PM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: Hi, My biggest concerns are those raised by Olaf- how do the two versions coexist. I will bet you that the solution we come up with will be EXACTLY the same, whether we add your new function or not. So, i want No, if we go and add an optional status function, this problem does not exist. I covered that in my mail. If we go that route and do a 1.1, the dll backend can load *.so.1* and be done with it. If it's a 1.1 backend, it will have the function defined, nothing more to do, if it's a 1.0 backend it won't have it and dll wires up a stub instead. All backends in 1.1 define the function, a stub is used for all the backends that are unmaintained today. There, done, no problem. Total backward compatibility with anything built against 1.0. No change in the behaviour of the current API calls. Some work to do on saned/net as the new call needs to added and the version check needs to be extended a bit (1.1 client cannot talk to a 1.0 saned or needs to wire up a stub call for the new call). No big issue, takes time and testing. but- as you have said several times in this thread, what about frontends that link to the backend, bypassing dll? They might get a frame-type they have never heard of, all while the backend says it follows major version 1, which the standard says will never happen. allan -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
Hello, On Nov 6 08:44 Olaf Meeuwissen wrote (shortened): - will a version 2 dll backend still load version 1 backends? - can version 2 frontends use version 1 backends? - will version 1 frontends do the right thing with all version 2 backends? - can everyone find the right match of versions? The mixed version installations is something that distribution will care about. A lot. Any distribution people hanging around that want to chime in here? If a mixed version installation does not work well, we can only wait and keep the old stuff until all what is important for us (sane-backends, sane-frontends, xsane, KDE scanning frontend) is ready to work and then switch completely to the new stuff. Backward compatibility (i.e. have no regression bugs) is usually more important than new features, in particular when new features are not essential to use a scanner. Additionally there is the LSB standard... By the way: Because of this we still have Iscan version 2.10, see https://bugzilla.novell.com/show_bug.cgi?id=425743 Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
[sane-devel] Sane Release 1.1.0 ?
m. allan noah kitno455 at gmail.com wrote: but- as you have said several times in this thread, what about frontends that link to the backend, bypassing dll? They might get a frame-type they have never heard of, all while the backend says it follows major version 1, which the standard says will never happen. I think we discussed that and the consensus was that if the frontend is well written it shouldn't be an issue. Is there actually a backend that feeds a new frame type to the frontend without the frontend asking for it? JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
sorry julien, should have included list On Thu, Nov 6, 2008 at 1:06 PM, m. allan noah kitno455 at gmail.com wrote: On Thu, Nov 6, 2008 at 1:02 PM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: but- as you have said several times in this thread, what about frontends that link to the backend, bypassing dll? They might get a frame-type they have never heard of, all while the backend says it follows major version 1, which the standard says will never happen. I think we discussed that and the consensus was that if the frontend is well written it shouldn't be an issue. Is there actually a backend that feeds a new frame type to the frontend without the frontend asking for it? If you want to split hairs, then yes, you might assume that. however, this leaves it up to the end user to know that his front-end cant handle jpeg, so dont set that option. That should get the Gnome guys panties in a wad :) In fact, adding a function is worse that i first though. A recent frontend could connect directly to an old backend, inspect the version number just like the standard says, and then call sane_status(). Bam! This never happens with our current design, because old backends are forward compatible. Any of these changes, function or enum, is an API/ABI change. The standard is clear: we must bump the version number. Oliver Rauch said as much and we should have listened... allan -- The truth is an offense, but not a sin -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
On Thu, Nov 6, 2008 at 1:16 PM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: In fact, adding a function is worse that i first though. A recent frontend could connect directly to an old backend, inspect the version number just like the standard says, and then call sane_status(). Bam! This never happens with our current design, because old backends are forward compatible. If you are using 1.1 features, you shouldn't use a 1.0 backend. If someone does that, they deserve the nice error message they'll be getting from the linker. if it hurts, don't do it See how quite a number of big projects do that nowadays, and it's perfectly fine. GTK and GNOME introduce new API calls all the time, and if you use them, you need to use the proper version. There's nothing wrong with that as long as a 1.1 backend works just like a 1.0 backend if the app expects a 1.0 backend. ok, so how can a front-end know that it has connected to a 1.0 backend, since the sane standard states that the minor and point release number are completely under the control of the backend? You want to make the minor number do exactly what the major number is supposed to do! allan -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
m. allan noah kitno455 at gmail.com wrote: In fact, adding a function is worse that i first though. A recent frontend could connect directly to an old backend, inspect the version number just like the standard says, and then call sane_status(). Bam! This never happens with our current design, because old backends are forward compatible. If you are using 1.1 features, you shouldn't use a 1.0 backend. If someone does that, they deserve the nice error message they'll be getting from the linker. if it hurts, don't do it See how quite a number of big projects do that nowadays, and it's perfectly fine. GTK and GNOME introduce new API calls all the time, and if you use them, you need to use the proper version. There's nothing wrong with that as long as a 1.1 backend works just like a 1.0 backend if the app expects a 1.0 backend. No surprises for older frontends, newer frontends know they use newer features and need newer libs. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
m. allan noah kitno455 at gmail.com wrote: ok, so how can a front-end know that it has connected to a 1.0 backend, since the sane standard states that the minor and point release number are completely under the control of the backend? You want to make the minor number do exactly what the major number is supposed to do! As long as older frontends don't have to care about running with a newer lib, there's no reason to bump the major. The standard was written at a time where adding features in a backward-compatible way was probably not standard practice, but it is nowadays. We deal with that in GTK and other libs all the time, everybody knows how it works and how to work with that. Not to mention glibc :) JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
On Thu, Nov 6, 2008 at 1:23 PM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: ok, so how can a front-end know that it has connected to a 1.0 backend, since the sane standard states that the minor and point release number are completely under the control of the backend? You want to make the minor number do exactly what the major number is supposed to do! As long as older frontends don't have to care about running with a newer lib, there's no reason to bump the major. 10 mails ago you chewed me out for not thinking about the ecosystem, and now you mean to ignore half of it? The standard was written at a time where adding features in a backward-compatible way was probably not standard practice, but it is nowadays. We deal with that in GTK and other libs all the time, everybody knows how it works and how to work with that. Not to mention glibc :) ok, then how do they do it? allan -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
m. allan noah kitno455 at gmail.com wrote: As long as older frontends don't have to care about running with a newer lib, there's no reason to bump the major. 10 mails ago you chewed me out for not thinking about the ecosystem, and now you mean to ignore half of it? WTF??? I say older frontends don't have to care whether they're running with a 1.0 or 1.1 lib and I'm ignoring something? nowadays. We deal with that in GTK and other libs all the time, everybody knows how it works and how to work with that. Not to mention glibc :) ok, then how do they do it? Adding symbols, and that's it. Symbol versioning is used by the glibc and also GTK now, but that's icing on the cake for what we're discussing here (and given our platform support, I'm not even sure symbol versioning is supported everywhere anyway). JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
On Thu, Nov 6, 2008 at 2:35 PM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: As long as older frontends don't have to care about running with a newer lib, there's no reason to bump the major. 10 mails ago you chewed me out for not thinking about the ecosystem, and now you mean to ignore half of it? WTF??? I say older frontends don't have to care whether they're running with a 1.0 or 1.1 lib and I'm ignoring something? if an older front-end gets a frametype it does not support it will likely choke. If we dont use the version number to protect it, we are forced to put everything new into a function call, which works for status, but not for frames. and then that breaks when a new front-end uses an old backend. see below- nowadays. We deal with that in GTK and other libs all the time, everybody knows how it works and how to work with that. Not to mention glibc :) ok, then how do they do it? Adding symbols, and that's it. Symbol versioning is used by the glibc and also GTK now, but that's icing on the cake for what we're discussing here (and given our platform support, I'm not even sure symbol versioning is supported everywhere anyway). Ok, but if they add symbols (without symbol versioning) then they must version the DSO in some way, right? allan -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
Le Thursday 06 November 2008 11:01:40 Julien BLACHE, vous avez ?crit?: stef stef.dev at free.fr wrote: to define a way both version can coexist we have to knowwhat are the cases which lead to this coexistence on a system. In my -possibly simplistic- view, since any out of tree backend only needs a mere recompile to get in sync, I don't see at first where is the problem. Could you tell me the precise cases you are thinking of ? samsung MFP backend. No sources. No maintainer. No hope for an update anytime soon. Shitload of users. Hello, this is the kind of headache binary only drivers provide. I have a GeForce Ti 4200 that I can't use yet on a recent kernel However, do you think we could manage to get such backends still working by: - installing sane 2 backends in a different directory (dll2.d ?) where sane 1 never search for backends - modify dll.c to search in sane1 directories when given a SANE 1 major, and sane 2 directories for SANE 2 major, possibly falling back to sane 1 directories if no backend is found. Regards, Stef
[sane-devel] Sane Release 1.1.0 ?
On Tue, Nov 4, 2008 at 5:22 PM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: Hi, damnit julien- it is called sane_status!, you dont get to declare that 'its not really a status, so lets not put statuses in it' it is just like SANE_STATUS_BUSY, where a backend might very well choose to retry after a few seconds. Hmm, SANE_STATUS_DEVICE_BUSY is actually often returned when the USB device cannot be opened because it's already in use by another process. I do make a difference between operation status and hardware status, and looking at SANE_Status, there's just nothing like the warming up thing in there at the moment. Though I concede that a couple of things are borderline. Maybe I should not try to put some sanity into SANE. Sanity is not the problem. The extreme need to make a release, coupled with limited developer resources is the problem. Lets bump the version everywhere to 2. allan -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
m. allan noah kitno455 at gmail.com wrote: Hi, Sanity is not the problem. The extreme need to make a release, coupled with limited developer resources is the problem. Lets bump the version everywhere to 2. Sanity and consistency of the API and its behaviour is the problem. And I just can't believe you're pushing a release because we need to release and breaking things along the way. I don't think doing the status thing the right way needs a lot of resources given there are only 2 or 3 backends that use that. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
On Wed, Nov 5, 2008 at 8:42 AM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: Hi, Sanity is not the problem. The extreme need to make a release, coupled with limited developer resources is the problem. Lets bump the version everywhere to 2. Sanity and consistency of the API and its behaviour is the problem. we are making only modest changes to the API. It's behaviour is MORE consistent with the current code than with your suggestion. And I just can't believe you're pushing a release because we need to release and breaking things along the way. This is YOUR opinion. I think adding additional statuses to SANE_Status is perfect, and protecting them with version bump follows the standard to the letter. I don't think doing the status thing the right way needs a lot of resources given there are only 2 or 3 backends that use that. Bah- you have to add your sane_status() call to all backends. I don't think it makes sense to touch them. allan -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
m. allan noah kitno455 at gmail.com wrote: This is YOUR opinion. Yeah, right. Go ahead, break it to pieces, I don't care anymore. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
On Wed, Nov 5, 2008 at 6:44 PM, Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: m. allan noah kitno455 at gmail.com writes: On Wed, Nov 5, 2008 at 8:42 AM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: Sanity is not the problem. The extreme need to make a release, coupled with limited developer resources is the problem. Lets bump the version everywhere to 2. Sanity and consistency of the API and its behaviour is the problem. we are making only modest changes to the API. It's behaviour is MORE consistent with the current code than with your suggestion. And I just can't believe you're pushing a release because we need to release and breaking things along the way. This is YOUR opinion. I think adding additional statuses to SANE_Status is perfect, and protecting them with version bump follows the standard to the letter. Julien is not the only one with that opinion. I for one don't care for a release that was pushed out of the door for the benefit of a mere three backends that want/need the additions and in the mean time break things along the way for all frontends and external backends. - what other reasons are there to release in such a rush? a rush? it will be 9 months since last release if we were to start the process today, and i never suggested that. i never even gave a timeline. - how do you support mixed (API/so)version installations? - will a version 2 dll backend still load version 1 backends? It should be able to, since old backends are forward compatible - can version 2 frontends use version 1 backends? unless the dll backend is going to change the version number, they will have to, because of external backends. - will version 1 frontends do the right thing with all version 2 backends? no, that is why there is a soversion bump. we HAVE to have some mechanism to make incompatible changes to the API. - can everyone find the right match of versions? most folks use the free backends we ship, and they will all be version 2. External backends that stay at v1 should still work. there is nothing in the standard that precludes a frontend from supporting two versions, or the dll backend could change the version as it passes by, and still be accurate, since a v1 backend works just like a v2 backend, but does not use the new statuses or frame types. I am open to suggestions on all these points. That is why I am pushing the issue, to get some ideas, and some help. allan -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
Julien BLACHE jb at jblache.org writes: stef stef.dev at free.fr wrote: Hi, Whenever a frontend built against SANE 1.0 receive one of the new status, it shows the error properly. Like SANE_STATUS_COVER_OPEN, JAMMED or NO_DOCS, in case of SANE_STATUS_WARMING_UP user has to correct the error condition (in this case just by waiting) before starting a new scan. When the error condition is fixed (scanner is warm enough), the scan goes normally. I have a frontend that calls sane_cancel() and throws an exception (and no plans to fix that any time real soon). I am worried this can break automated frontends in a semi-random way as it's possible with some hardware to get back a warming up status in a middle of a run. Indeed. Although the frontends can be fixed pretty easily, it violates the principle of least surprise, and it's kind of a problem. Also, I doubt that all Linux distributions can get all their frontends fixed in time for their next release. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
[sane-devel] Sane Release 1.1.0 ?
stef stef.dev at free.fr writes: Le Wednesday 29 October 2008 19:59:09 Julien BLACHE, vous avez ?crit?: Nicolas Martin nicolas.martin at freesurf.fr wrote: ... Also calling the current CVS SANE 2.0 is really a bad joke given there's only very little changes compared to SANE 1.0. I don't think it's warranted and I don't think it's a good thing. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169 Hello, there are only 2 changes in the SANE API: - new SANE_FRAME values - new SANE_STATUS Whenever a frontend built against SANE 1.0 receive one of the new status, it shows the error properly. Like SANE_STATUS_COVER_OPEN, JAMMED or NO_DOCS, in case of SANE_STATUS_WARMING_UP user has to correct the error condition (in this case just by waiting) before starting a new scan. When the error condition is fixed (scanner is warm enough), the scan goes normally. For the new frame formats (tested with a hacked pnm backend), when XSane receives a format it doesn't know, there is a 'Bad frame format 11' pop-up. Kooka doesn't send any error, and user gets a black scan . So the current picture of using a SANE 1.0 frontend against a SANE 'next version' is that there may be some errors in the case the user requires an frame format that isn't known for the frontend. Currently only the bh, coolscan3 and fujitsu backends take advantage of the new SANE_FRAME values. Any frontend using the dll backend will be affected, in principle. If you think -as a package maintainer- these errors are important enough to require a V_MAJOR increase, we'll have to call next SANE version SANE 2.0 due to the way the standard worked (only the major is taken into account), and the way backends misused V_MAJOR instead of SANE_CURRENT_MAJOR. For all I know, all backends but one still misuse V_MAJOR. Personally, I am of the opinion that we should clean up the version mess first and come up with a workable and backwardly compatible versioning scheme. Any such scheme should allow for simultaneous installation of multiple (major) versions. I am comfortable with releasing the current CVS as SANE 2.0 even the amount of API change is minimal since is has a technical merit. Keeping the current work as SANE 1.1 doesn't disturb either since the errors would be limited, but I'm not the one that will have to cope with the bug reports. But i definitely want a conclusion to be taken regarding how to call next version 2.0 or 1.1. What version are you talking about here? I agree with Julien that bumping the API specification version to 2.0 is a bad joke. Bumping the soversion of those backends that actually support/use the additions to 2 is the Right Thing to do, however. # Note that the current dll backend implementation does NOT support a # mixed soversion scenario. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
[sane-devel] Sane Release 1.1.0 ?
Le Monday 03 November 2008 11:04:09 Julien BLACHE, vous avez ?crit?: stef stef.dev at free.fr wrote: Hi, Whenever a frontend built against SANE 1.0 receive one of the new status, it shows the error properly. Like SANE_STATUS_COVER_OPEN, JAMMED or NO_DOCS, in case of SANE_STATUS_WARMING_UP user has to correct the error condition (in this case just by waiting) before starting a new scan. When the error condition is fixed (scanner is warm enough), the scan goes normally. I am worried this can break automated frontends in a semi-random way as it's possible with some hardware to get back a warming up status in a middle of a run. Although the frontends can be fixed pretty easily, it violates the principle of least surprise, and it's kind of a problem. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169 OK, so at least a V_MAJOR increase is needed then. Regards, Stef
[sane-devel] Sane Release 1.1.0 ?
Le Tuesday 04 November 2008 03:02:07 Olaf Meeuwissen, vous avez ?crit?: stef stef.dev at free.fr writes: Le Wednesday 29 October 2008 19:59:09 Julien BLACHE, vous avez ?crit?: Nicolas Martin nicolas.martin at freesurf.fr wrote: ... Also calling the current CVS SANE 2.0 is really a bad joke given there's only very little changes compared to SANE 1.0. I don't think it's warranted and I don't think it's a good thing. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169 Hello, there are only 2 changes in the SANE API: - new SANE_FRAME values - new SANE_STATUS Whenever a frontend built against SANE 1.0 receive one of the new status, it shows the error properly. Like SANE_STATUS_COVER_OPEN, JAMMED or NO_DOCS, in case of SANE_STATUS_WARMING_UP user has to correct the error condition (in this case just by waiting) before starting a new scan. When the error condition is fixed (scanner is warm enough), the scan goes normally. For the new frame formats (tested with a hacked pnm backend), when XSane receives a format it doesn't know, there is a 'Bad frame format 11' pop-up. Kooka doesn't send any error, and user gets a black scan . So the current picture of using a SANE 1.0 frontend against a SANE 'next version' is that there may be some errors in the case the user requires an frame format that isn't known for the frontend. Currently only the bh, coolscan3 and fujitsu backends take advantage of the new SANE_FRAME values. Any frontend using the dll backend will be affected, in principle. If you think -as a package maintainer- these errors are important enough to require a V_MAJOR increase, we'll have to call next SANE version SANE 2.0 due to the way the standard worked (only the major is taken into account), and the way backends misused V_MAJOR instead of SANE_CURRENT_MAJOR. For all I know, all backends but one still misuse V_MAJOR. Personally, I am of the opinion that we should clean up the version mess first and come up with a workable and backwardly compatible versioning scheme. Any such scheme should allow for simultaneous installation of multiple (major) versions. The clean-up you are thinking of is going through all the sane_init function in all backends and change the version code building to use SANE_CURRENT_MAJOR ? I am comfortable with releasing the current CVS as SANE 2.0 even the amount of API change is minimal since is has a technical merit. Keeping the current work as SANE 1.1 doesn't disturb either since the errors would be limited, but I'm not the one that will have to cope with the bug reports. But i definitely want a conclusion to be taken regarding how to call next version 2.0 or 1.1. What version are you talking about here? SANE current CVS which has SANE 1.1 version in code. I agree with Julien that bumping the API specification version to 2.0 is a bad joke. Bumping the soversion of those backends that actually support/use the additions to 2 is the Right Thing to do, however. Feature wise, it is heavy handed to call it 2.0, but it sides step issues with unmaintained backends that would have been to be changed. But also, having a current major change would allow in dll.c to choose between a sane1/sane2 subdir based on the major required by the frontend, providing esay coexistence of both versions. # Note that the current dll backend implementation does NOT support a # mixed soversion scenario. I agree with you, fontends that follow the SANE API (such as xsane and gnoescan) use only the major number to check the compatibility. libkscan doesn't check anything and as then no troubles. Hope this helps, Regards, Stef
[sane-devel] Sane Release 1.1.0 ?
stef stef.dev at free.fr writes: Le Tuesday 04 November 2008 03:02:07 Olaf Meeuwissen, vous avez ?crit?: stef stef.dev at free.fr writes: Le Wednesday 29 October 2008 19:59:09 Julien BLACHE, vous avez ?crit?: Nicolas Martin nicolas.martin at freesurf.fr wrote: ... Also calling the current CVS SANE 2.0 is really a bad joke given there's only very little changes compared to SANE 1.0. I don't think it's warranted and I don't think it's a good thing. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169 Hello, there are only 2 changes in the SANE API: - new SANE_FRAME values - new SANE_STATUS Whenever a frontend built against SANE 1.0 receive one of the new status, it shows the error properly. Like SANE_STATUS_COVER_OPEN, JAMMED or NO_DOCS, in case of SANE_STATUS_WARMING_UP user has to correct the error condition (in this case just by waiting) before starting a new scan. When the error condition is fixed (scanner is warm enough), the scan goes normally. For the new frame formats (tested with a hacked pnm backend), when XSane receives a format it doesn't know, there is a 'Bad frame format 11' pop-up. Kooka doesn't send any error, and user gets a black scan . So the current picture of using a SANE 1.0 frontend against a SANE 'next version' is that there may be some errors in the case the user requires an frame format that isn't known for the frontend. Currently only the bh, coolscan3 and fujitsu backends take advantage of the new SANE_FRAME values. Any frontend using the dll backend will be affected, in principle. If you think -as a package maintainer- these errors are important enough to require a V_MAJOR increase, we'll have to call next SANE version SANE 2.0 due to the way the standard worked (only the major is taken into account), and the way backends misused V_MAJOR instead of SANE_CURRENT_MAJOR. For all I know, all backends but one still misuse V_MAJOR. Personally, I am of the opinion that we should clean up the version mess first and come up with a workable and backwardly compatible versioning scheme. Any such scheme should allow for simultaneous installation of multiple (major) versions. The clean-up you are thinking of is going through all the sane_init function in all backends and change the version code building to use SANE_CURRENT_MAJOR ? That's only part of what I was thinking about but, yes, fixing the abuse of V_MAJOR in the current backends is the first step. Other things that need to be addressed are: - dealing with different soversions of backends that implement the same major version of the SANE API specification - decide how we want to handle minor version updates to the SANE API specification, if at all - dealing with sane-backends packages that cater to different major versions of the SANE API specification - clean upgrade paths for frontends and backends (including external frontends and backends) I am comfortable with releasing the current CVS as SANE 2.0 even the amount of API change is minimal since is has a technical merit. Keeping the current work as SANE 1.1 doesn't disturb either since the errors would be limited, but I'm not the one that will have to cope with the bug reports. But i definitely want a conclusion to be taken regarding how to call next version 2.0 or 1.1. What version are you talking about here? SANE current CVS which has SANE 1.1 version in code. You seem to be talking about the package version then. Yeay! Yet another number that potentially adds to the version confusion. I agree with Julien that bumping the API specification version to 2.0 is a bad joke. Bumping the soversion of those backends that actually support/use the additions to 2 is the Right Thing to do, however. Feature wise, it is heavy handed to call it 2.0, but it sides step issues with unmaintained backends that would have been to be changed. But also, having a current major change would allow in dll.c to choose between a sane1/sane2 subdir based on the major required by the frontend, providing esay coexistence of both versions. That assumes that the dll backend knows how to handle both versions. It also needs changes in the way the dll backend locates other backends as it currently only searches the $pkglibdir for libraries that match libsane-*.so.$V_MAJOR and are listed in dll.conf. # Slightly off topic, I would like to see support for recursion into # subdirectories as that makes it easier to maintain external/vendor # backends. # Note that the current dll backend implementation does NOT support a # mixed soversion scenario. I agree with you, fontends that follow the SANE API (such as xsane and gnoescan) use only the major number to check the compatibility. libkscan doesn't
[sane-devel] Sane Release 1.1.0 ?
Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: Hi, I have a frontend that calls sane_cancel() and throws an exception (and no plans to fix that any time real soon). The problem with the warming up thing is that it is not an error, it's a /transient/ *status* that clears itself up with time. So it's wrong for an operation to FAIL because of this. It's the kind of thing that should not be part of SANE_Status (bad naming for that, btw, as we see), but should be treated on its own. We should add a sane_status() call to the API to handle this kind of things, so the call flow becomes: sane_start() sane_status() - warming up: tell the user the scanner is not ready, poll sane_status() until it's ready (but don't busy loop) - OK: go ahead sane_read() And the better part is, we can make it an optional call and keep the current behaviour for SANE 1.0 frontends, effectively enabling a backward-compatible SANE 1.1 evolution of the standard. Later we can make it mandatory in the call flow for SANE 2.0 - then sane_read() can bomb out in SANE 2.0 with a sorry, not ready if the scanner is not ready for whatever reason and the caller did not bother to check beforehand (or did and things changed). sane_status() then tells you what's up. Other status returned by sane_status() could be things like: stand by, lamp off, lamp on, ... the status could be a bitfield. sane_status() could be called at any time between sane_open() and sane_close() without ill effects. Again, the whole problem with warming up is that it makes no sense to have an operation fail because of that; it's wrong wrong wrong, no matter how you put it it's still wrong wrong wrong. A paper jammed error is a permanent error condition until the user clears it up. There's no point in having the frontend wait for the error to clear in this case, because it'll take time and the scanner will probably be switched off for that and/or need a reinit anyway. Bailing out is the right thing to do here. I hope this clears things up, and I'd very much like to see that implemented that way. It makes much more sense, it's much more useful and extensible IMHO. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
Le Tuesday 04 November 2008 11:57:15 Julien BLACHE, vous avez ?crit?: Olaf Meeuwissen olaf.meeuwissen at avasys.jp wrote: Hi, I have a frontend that calls sane_cancel() and throws an exception (and no plans to fix that any time real soon). The problem with the warming up thing is that it is not an error, it's a /transient/ *status* that clears itself up with time. So it's wrong for an operation to FAIL because of this. It's the kind of thing that should not be part of SANE_Status (bad naming for that, btw, as we see), but should be treated on its own. We should add a sane_status() call to the API to handle this kind of things, so the call flow becomes: sane_start() sane_status() - warming up: tell the user the scanner is not ready, poll sane_status() until it's ready (but don't busy loop) - OK: go ahead sane_read() And the better part is, we can make it an optional call and keep the current behaviour for SANE 1.0 frontends, effectively enabling a backward-compatible SANE 1.1 evolution of the standard. Later we can make it mandatory in the call flow for SANE 2.0 - then sane_read() can bomb out in SANE 2.0 with a sorry, not ready if the scanner is not ready for whatever reason and the caller did not bother to check beforehand (or did and things changed). sane_status() then tells you what's up. Other status returned by sane_status() could be things like: stand by, lamp off, lamp on, ... the status could be a bitfield. sane_status() could be called at any time between sane_open() and sane_close() without ill effects. Again, the whole problem with warming up is that it makes no sense to have an operation fail because of that; it's wrong wrong wrong, no matter how you put it it's still wrong wrong wrong. A paper jammed error is a permanent error condition until the user clears it up. There's no point in having the frontend wait for the error to clear in this case, because it'll take time and the scanner will probably be switched off for that and/or need a reinit anyway. Bailing out is the right thing to do here. I hope this clears things up, and I'd very much like to see that implemented that way. It makes much more sense, it's much more useful and extensible IMHO. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169 Hello, I agree with the design you are explaining. But the trouble with such approach is that adding new function to the API had been rejected so that many unmaintained (or untestable due to lack of hardware) backends can be left untouched. Also there haven't been a new SANE standards for years (SANE 2 last draft will be 6 years old in December) , and presumably, there will be never. Adding one more status is then the only way to provide user a feeback when the scanner is doing nothing (from user's point of view) during 30s. For me this 'warming thing' isn't a pet feature, it is a clear sign of the importance we give to the people using our backends. Regards, Stef
[sane-devel] Sane Release 1.1.0 ?
stef stef.dev at free.fr wrote: Hi, I agree with the design you are explaining. But the trouble with such approach is that adding new function to the API had been rejected so that many unmaintained (or untestable due to lack of hardware) backends can be That's actually not an issue. We can add a stub in those backends, and we can put logic in the dll backend to use a stub if the backend being loaded doesn't have sane_status() (think binary-only backends). That stub would just tell not supported and we're done with it. As I said, if we make sane_status() optional and retain the current behaviour for sane_start() for all backends (aka just sit there until the scanner is done warming up), we're in the clear. left untouched. Also there haven't been a new SANE standards for years (SANE 2 last draft will be 6 years old in December) , and presumably, there will be Yes. We have a problem here, as in we haven't found a way to go forward yet with evolutions to the standard. It's a big problem. never. Adding one more status is then the only way to provide user a feeback when the scanner is doing nothing (from user's point of view) during 30s. The problem is that SANE_Status is not a *status*, it's actually an *error code* and you're abusing it with the warming up thing. From there on, everything breaks. It is not the proper interface. For me this 'warming thing' isn't a pet feature, it is a clear sign of the importance we give to the people using our backends. I never said it is a pet feature. As the owner and user of a pair of Epson scanners that can sit there for 30+ seconds during warm up, I'd very much like to see this implemented, but PLEASE let's do it properly. Breaking interfaces and bending the standard to make things fit is not going to help going forward. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
On Tue, Nov 4, 2008 at 4:04 PM, Julien BLACHE jb at jblache.org wrote: stef stef.dev at free.fr wrote: Hi, I agree with the design you are explaining. But the trouble with such approach is that adding new function to the API had been rejected so that many unmaintained (or untestable due to lack of hardware) backends can be That's actually not an issue. We can add a stub in those backends, and we can put logic in the dll backend to use a stub if the backend being loaded doesn't have sane_status() (think binary-only backends). That stub would just tell not supported and we're done with it. As I said, if we make sane_status() optional and retain the current behaviour for sane_start() for all backends (aka just sit there until the scanner is done warming up), we're in the clear. left untouched. Also there haven't been a new SANE standards for years (SANE 2 last draft will be 6 years old in December) , and presumably, there will be Yes. We have a problem here, as in we haven't found a way to go forward yet with evolutions to the standard. It's a big problem. never. Adding one more status is then the only way to provide user a feeback when the scanner is doing nothing (from user's point of view) during 30s. The problem is that SANE_Status is not a *status*, it's actually an *error code* and you're abusing it with the warming up thing. From there on, everything breaks. It is not the proper interface. For me this 'warming thing' isn't a pet feature, it is a clear sign of the importance we give to the people using our backends. I never said it is a pet feature. As the owner and user of a pair of Epson scanners that can sit there for 30+ seconds during warm up, I'd very much like to see this implemented, but PLEASE let's do it properly. Breaking interfaces and bending the standard to make things fit is not going to help going forward. damnit julien- it is called sane_status!, you dont get to declare that 'its not really a status, so lets not put statuses in it' it is just like SANE_STATUS_BUSY, where a backend might very well choose to retry after a few seconds. allan -- The truth is an offense, but not a sin
[sane-devel] Sane Release 1.1.0 ?
m. allan noah kitno455 at gmail.com wrote: Hi, damnit julien- it is called sane_status!, you dont get to declare that 'its not really a status, so lets not put statuses in it' it is just like SANE_STATUS_BUSY, where a backend might very well choose to retry after a few seconds. Hmm, SANE_STATUS_DEVICE_BUSY is actually often returned when the USB device cannot be opened because it's already in use by another process. I do make a difference between operation status and hardware status, and looking at SANE_Status, there's just nothing like the warming up thing in there at the moment. Though I concede that a couple of things are borderline. Maybe I should not try to put some sanity into SANE. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
Le Wednesday 29 October 2008 19:59:09 Julien BLACHE, vous avez ?crit?: Nicolas Martin nicolas.martin at freesurf.fr wrote: ... Also calling the current CVS SANE 2.0 is really a bad joke given there's only very little changes compared to SANE 1.0. I don't think it's warranted and I don't think it's a good thing. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169 Hello, there are only 2 changes in the SANE API: - new SANE_FRAME values - new SANE_STATUS Whenever a frontend built against SANE 1.0 receive one of the new status, it shows the error properly. Like SANE_STATUS_COVER_OPEN, JAMMED or NO_DOCS, in case of SANE_STATUS_WARMING_UP user has to correct the error condition (in this case just by waiting) before starting a new scan. When the error condition is fixed (scanner is warm enough), the scan goes normally. For the new frame formats (tested with a hacked pnm backend), when XSane receives a format it doesn't know, there is a 'Bad frame format 11' pop-up. Kooka doesn't send any error, and user gets a black scan . So the current picture of using a SANE 1.0 frontend against a SANE 'next version' is that there may be some errors in the case the user requires an frame format that isn't known for the frontend. Currently only the bh, coolscan3 and fujitsu backends take advantage of the new SANE_FRAME values. If you think -as a package maintainer- these errors are important enough to require a V_MAJOR increase, we'll have to call next SANE version SANE 2.0 due to the way the standard worked (only the major is taken into account), and the way backends misused V_MAJOR instead of SANE_CURRENT_MAJOR. I am comfortable with releasing the current CVS as SANE 2.0 even the amount of API change is minimal since is has a technical merit. Keeping the current work as SANE 1.1 doesn't disturb either since the errors would be limited, but I'm not the one that will have to cope with the bug reports. But i definitely want a conclusion to be taken regarding how to call next version 2.0 or 1.1. Regards, Stef
[sane-devel] Sane Release 1.1.0 ?
stef stef.dev at free.fr wrote: Hi, Whenever a frontend built against SANE 1.0 receive one of the new status, it shows the error properly. Like SANE_STATUS_COVER_OPEN, JAMMED or NO_DOCS, in case of SANE_STATUS_WARMING_UP user has to correct the error condition (in this case just by waiting) before starting a new scan. When the error condition is fixed (scanner is warm enough), the scan goes normally. I am worried this can break automated frontends in a semi-random way as it's possible with some hardware to get back a warming up status in a middle of a run. Although the frontends can be fixed pretty easily, it violates the principle of least surprise, and it's kind of a problem. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
My concern was not too much about the release number or name, but a focus on: have we some kind of schedule or forecast for a new Sane release ? Some very popular Linux distribution have releases twice a year, and I think this could be also a convenient rate for Sane too, to keep in sync with that. Nicolas Le mardi 28 octobre 2008 ? 21:42 +0100, stef a ?crit : Le Tuesday 28 October 2008 08:49:38 Ren? Kjellerup, vous avez ?crit : IIRC the version bumb to 1.0.19 was opted for Instead of the minor version bumb. Hello, I have seen no such conclusion. Kind Regards Ren? Kjellerup In order to have a clear picture of what developers want, I think it is time to anyone to express its choice. Mine is to have the current CVS released as SANE 2.0 with the according soname increase. Regards, Stef
[sane-devel] Sane Release 1.1.0 ?
Hallo, On 2008-10-29 08:26, Nicolas Martin wrote: My concern was not too much about the release number or name, but a focus on: have we some kind of schedule or forecast for a new Sane release ? Some very popular Linux distribution have releases twice a year, and I think this could be also a convenient rate for Sane too, to keep in sync with that. Sorry for jumping in here. Some very venerable, stable and reliable Linux distributions release 'when ready', ie. when after some time of testing there are 0 critical bugs. I'd always prefer a 'ready' release without bugs to one that just is on schedule... Of course, that's just my 2ct. Nicolas Johannes
[sane-devel] Sane Release 1.1.0 ?
i am inclined to agree with stef for 3 reasons: 1. it involves the least amount of code change. 2. it keeps the soversion and major number in sync, which is more obvious to frontend authors. 3. i am not worried about bringing out sane3 quickly. if history be our guide, that is years away. allan On Tue, Oct 28, 2008 at 4:42 PM, stef stef.dev at free.fr wrote: Le Tuesday 28 October 2008 08:49:38 Ren? Kjellerup, vous avez ?crit : IIRC the version bumb to 1.0.19 was opted for Instead of the minor version bumb. Hello, I have seen no such conclusion. Kind Regards Ren? Kjellerup In order to have a clear picture of what developers want, I think it is time to anyone to express its choice. Mine is to have the current CVS released as SANE 2.0 with the according soname increase. Regards, Stef -- 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] Sane Release 1.1.0 ?
I would agree if ... we had a particular goal or specification to reach, but not sure Sane is developed in this spirit. Sane is in a perpetual evolution process, and is IMHO ... never ?ready, with 0 bugs?. Newer scanner models come in, newer or upgraded backends come out, in a continuous workflow, regularly sampled to propose updated production packages for use. Linux distributions will probably never propose Sane CVS versions, and many end users will really only use what their distribution proposes. As scanner equipments become obsolete or commercially outdated after a while, releasing on a regular basis can give the latest Sane features available out of the box in these distributions, and thus, to most end users. Other similar tools, like gimp-print/gutenprint, have a tight releasing schedule, well suited to printer evolutions. My advice here would be to tend, if possible, to a similar approach for Sane. A release schedule frequency around twice a year, seems to me a good target. Nicolas Johannes Wiedersich jowied at googlemail.com a ?crit?: Hallo, On 2008-10-29 08:26, Nicolas Martin wrote: My concern was not too much about the release number or name, but a focus on: have we some kind of schedule or forecast for a new Sane release ? Some very popular Linux distribution have releases twice a year, and I think this could be also a convenient rate for Sane too, to keep in sync with that. Sorry for jumping in here. Some very venerable, stable and reliable Linux distributions release 'when ready', ie. when after some time of testing there are 0 critical bugs. I'd always prefer a 'ready' release without bugs to one that just is on schedule... Of course, that's just my 2ct. Nicolas Johannes -- 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 -- Nicolas
[sane-devel] Sane Release 1.1.0 ?
Nicolas Martin nicolas.martin at freesurf.fr wrote: Hi, I would agree if ... we had a particular goal or specification to reach, but not sure Sane is developed in this spirit. Sane is in a perpetual evolution process, and is IMHO ... never ?ready, with 0 bugs?. Then s/bugs/regressions/ at the very least. There are regressions in the avision backend in 1.0.19 that still haven't been fixed, for instance. I don't even know if the backend is still being developed or if anything is being done or has been done, as Rene does not use the SANE CVS for his development and his SVN repository has been unavailable for the past few months. So before releasing anything, there are little things like that to fix in the release development process. Also calling the current CVS SANE 2.0 is really a bad joke given there's only very little changes compared to SANE 1.0. I don't think it's warranted and I don't think it's a good thing. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] Sane Release 1.1.0 ?
Le Tuesday 28 October 2008 08:49:38 Ren? Kjellerup, vous avez ?crit?: IIRC the version bumb to 1.0.19 was opted for Instead of the minor version bumb. Hello, I have seen no such conclusion. Kind Regards Ren? Kjellerup In order to have a clear picture of what developers want, I think it is time to anyone to express its choice. Mine is to have the current CVS released as SANE 2.0 with the according soname increase. Regards, Stef
[sane-devel] Sane Release 1.1.0 ?
Is there any new schedule forecast for a Sane 1.1.0 release ? (last timetable I had in mind was a release during last July) Nicolas
[sane-devel] SANE release delayed until Feb 10
I've had guests this weekend, which has prevented me from committing some pending changes, and doing various release-related work. We've also seen some changes come in from other devels, and have a pending regression fix for one backend. As such, I am going to hold off the release until next weekend. I am about to commit a bunch of gcc warning fixes, mostly (char *) casts in str*() function calls, so everyone watch out for your personal backend getting updated... allan -- The truth is an offense, but not a sin
[sane-devel] SANE Release?
m. allan noah kitno455 at gmail.com wrote: Hi, can you make me a project admin on alioth so i can update those pages? I've added you as a project admin, if you need help for the release, feel free to ask me. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] SANE Release?
It's been 15 months since SANE 1.0.18 was released. In that time, we've had a few new backends added, many bugs fixed and new models supported. With Henning being so busy, I am offering to take the lead on releasing 1.0.19. However, I will need some handholding, so if Henning (or anyone else for that matter :) wants to do it instead, I would be happy. comments? allan -- The truth is an offense, but not a sin
[sane-devel] SANE Release?
Hi, On 2007-11-15 13:58, m. allan noah wrote: It's been 15 months since SANE 1.0.18 was released. In that time, we've had a few new backends added, many bugs fixed and new models supported. Good idea to make a new release! With Henning being so busy, I am offering to take the lead on releasing 1.0.19. However, I will need some handholding, so if Henning (or anyone else for that matter :) wants to do it instead, I would be happy. I won't have enough time... There is a guideline in doc/releases.txt that might help. Uploading is done only to alioth (FTP+HTTP) as rpm.org does not exist anymore. Good luck! Bye, Henning
[sane-devel] SANE Release?
can you make me a project admin on alioth so i can update those pages? allan On Nov 15, 2007 3:35 PM, Henning Geinitz sane at geinitz.org wrote: Hi, On 2007-11-15 13:58, m. allan noah wrote: It's been 15 months since SANE 1.0.18 was released. In that time, we've had a few new backends added, many bugs fixed and new models supported. Good idea to make a new release! With Henning being so busy, I am offering to take the lead on releasing 1.0.19. However, I will need some handholding, so if Henning (or anyone else for that matter :) wants to do it instead, I would be happy. I won't have enough time... There is a guideline in doc/releases.txt that might help. Uploading is done only to alioth (FTP+HTTP) as rpm.org does not exist anymore. Good luck! Bye, Henning -- 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] SANE Release?
Hi, This would be very nice to have a release allowing major distros to ship with updated SANE for next spring. Ubuntu ships CVS version of SANE (2007-05-05). There is definitily a needs for a new release. Regards, ?tienne -- E Ultre?a !
[sane-devel] SANE Release?
?tienne Bersac bersace at gmail.com wrote: Hi, This would be very nice to have a release allowing major distros to ship with updated SANE for next spring. Ubuntu ships CVS version of SANE (2007-05-05). There is definitily a needs for a new release. As far as Ubuntu goes, they're just shipping whatever I decide to ship in Debian. And if it lands in Debian you can be sure that it's suitable for release. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
