[sane-devel] The future of the SANE-Standard (was: permission request)
Hi all, On Wednesday 19 December 2007 19:17:12 m. allan noah wrote: On Dec 19, 2007 12:48 PM, Oliver Rauch Oliver.Rauch at rauch-domain.de wrote: Hello. As most of you know I am against the recent development of the SANE1 standard. We have an almost complete SANE2 standard and a good working SANE1 standard. What is happening in the moment is the destruction of all we have. This will end in a chaos. I don`t understand why nobody wants to start with SANE2. It will take a weekend of work to create a SANE2 backend from an existing SANE1 backend. Because you don`t want to spend this time you destroy the SANE1 standard by creating a chaos. As you say 95% of the users are happy with SANE1. What you are doing now is to make 95% of the users unhappy. When you will do what you are talking about in the moment then I will have to think if I will spend any further time into the SANE project and into xsane. I know if I would continue the work for xsane in this case then I would have to spend 99% of my programming time to answer questions about incompatibilities and problems with the new 1.1-standard. In my opinion it is not fair to create so much problems for SANE1 because you don`t like to spend some days to create SANE2 backends from the SANE1 backends. Please think about what you are doing. Oliver- The changes we discuss are minimal and are not the default output format for any backend. As such, they will not break existing front-ends until the user enables some option. Even then, they will only break a poorly written frontend. And so, it is my preference to place these changes right in sane 1.0. The idea to place them in sane 1.1 instead was purely a compromise to make YOU happy. But it seems that you are not interested in a simple upgrade path to help those remaining 5% of users, but instead want to tell us all to convert our backends and front-ends to SANE2. Please, meet us half-way, and stop using words like 'force' and 'chaos' in every discussion, and stop insisting that SANE2 is the only means to extend sane. That tactic has not worked for the past 5 years, and it does not work now. I just wanted to let you know that I fully agree with your position Allan. Happy xmas and a happy new year, Ren? -- Ren? Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name
[sane-devel] The future of the SANE-Standard
On Wed, 19 Dec 2007 15:48:47 -0500 m. allan noah kitno455 at gmail.com wrote: button handling, if done thru well-known options, and hotplug could be handled in any version of sane, provided we could find some folks with the time and urge to work on it. if button handling is done in some sort of async or call-back mode, that would require changing the API, so it would get pushed back to a later version (sane 2 maybe?) agreed. btw, in order to guarantee the maximum capability of sane 1.1 toward sane 1.0, I was thinking about a way for a frontend to explicitly enable the 1.1 features/frame types. for example, an 1.1 capable frontend might use an api call to enable them, after having checked for sane version 1.0 . opinions? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
On 12/21/07, Alessandro Zummo azummo-lists at towertech.it wrote: On Wed, 19 Dec 2007 15:48:47 -0500 m. allan noah kitno455 at gmail.com wrote: button handling, if done thru well-known options, and hotplug could be handled in any version of sane, provided we could find some folks with the time and urge to work on it. if button handling is done in some sort of async or call-back mode, that would require changing the API, so it would get pushed back to a later version (sane 2 maybe?) agreed. btw, in order to guarantee the maximum capability of sane 1.1 toward sane 1.0, I was thinking about a way for a frontend to explicitly enable the 1.1 features/frame types. for example, an 1.1 capable frontend might use an api call to enable them, after having checked for sane version 1.0 . its a good idea if we use a well-known boolean option to control it. if we add a function call, then we have to add that function to every backend, including external ones. i am specifically trying to avoid that. we already have an 'advanced' group, so i dont want to call it that, how about '--extended'? allan -- The truth is an offense, but not a sin
[sane-devel] The future of the SANE-Standard
On Fri, 21 Dec 2007 07:56:40 -0500 m. allan noah kitno455 at gmail.com wrote: its a good idea if we use a well-known boolean option to control it. if we add a function call, then we have to add that function to every backend, including external ones. i am specifically trying to avoid that. in theory that function call will be called only if the backend has version = 1.1, so external backends would not require it. or I am missing something? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
On Dec 21, 2007 8:55 AM, Alessandro Zummo azummo-lists at towertech.it wrote: On Fri, 21 Dec 2007 07:56:40 -0500 m. allan noah kitno455 at gmail.com wrote: its a good idea if we use a well-known boolean option to control it. if we add a function call, then we have to add that function to every backend, including external ones. i am specifically trying to avoid that. in theory that function call will be called only if the backend has version = 1.1, so external backends would not require it. or I am missing something? well, i wanted to minimize the changes to front-ends, other than dropping unknown frame types. also, this sets up a precedent for backends needing to have 'modes' where they support historical versions of the sane standard. in this case, that is not a problem, but in the future, it might be. are you proposing that we update every backend in sane with this function- because they are all going to get their minor version number bumped to 1, to match their new sonames... allan -- The truth is an offense, but not a sin
[sane-devel] The future of the SANE-Standard
Alessandro Zummo azummo-lists at towertech.it wrote: Hi, i have not yet checked the matter in the sane source but, if we add the api call to dll.c and not in the backend, what will happen? I'll supply Oliver Rauch with a large quantity of LARTs and your real-world address. :-) (bottom line: keep the exported API of dll and other backends in sync) JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] The future of the SANE-Standard
On Fri, 21 Dec 2007 15:44:21 +0100 Julien BLACHE jb at jblache.org wrote: Alessandro Zummo azummo-lists at towertech.it wrote: Hi, i have not yet checked the matter in the sane source but, if we add the api call to dll.c and not in the backend, what will happen? I'll supply Oliver Rauch with a large quantity of LARTs and your real-world address. :-) (bottom line: keep the exported API of dll and other backends in sync) ouch! :-D can't dll.c provide dummy functions for unavailable functions in backends? if not, we need another way to avoid exposing new frame format to unaware backends. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
On Dec 21, 2007 9:33 AM, Alessandro Zummo azummo-lists at towertech.it wrote: On Fri, 21 Dec 2007 09:12:56 -0500 m. allan noah kitno455 at gmail.com wrote: well, i wanted to minimize the changes to front-ends, other than dropping unknown frame types. also, this sets up a precedent for backends needing to have 'modes' where they support historical versions of the sane standard. in this case, that is not a problem, but in the future, it might be. are you proposing that we update every backend in sane with this function- because they are all going to get their minor version number bumped to 1, to match their new sonames... i'm just thinking about it, so it is not a proposal at this time. i have not yet checked the matter in the sane source but, if we add the api call to dll.c and not in the backend, what will happen? a) segfault b) SANE_STATUS_NOT_SUPPORTED ? if b, we would not need to update the backends. if a) then it is not the way to go. I do not like changing every backend. but if we can change little in dll/real 1.1 backends that would be fine. if the dll backend had no mechanism to determine existence of the call beforehand, i assume it would segfault. besides, this assumes that all callers will link against the dll backend exclusively- every backend exports the same interface, so that frontends can link against them directly. i would not want to break that. so- if we want to protect front-ends from the updated backends- the only mechanism we have is a well-known option. instead of a boolean, how about a string list- then a backend can report what versions of the standard it supports, and the frontend or user can chose. allan -- The truth is an offense, but not a sin
[sane-devel] The future of the SANE-Standard
On Fri, 21 Dec 2007 09:47:13 -0500 m. allan noah kitno455 at gmail.com wrote: On Dec 21 I do not like changing every backend. but if we can change little in dll/real 1.1 backends that would be fine. if the dll backend had no mechanism to determine existence of the call beforehand, i assume it would segfault. besides, this assumes that all callers will link against the dll backend exclusively- every backend exports the same interface, so that frontends can link against them directly. i would not want to break that. mm think I had missed this. so- if we want to protect front-ends from the updated backends- the only mechanism we have is a well-known option. instead of a boolean, how about a string list- then a backend can report what versions of the standard it supports, and the frontend or user can chose. I guess that would work! :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
On Fri, 21 Dec 2007 10:06:09 -0500 m. allan noah kitno455 at gmail.com wrote: only mechanism we have is a well-known option. instead of a boolean, how about a string list- then a backend can report what versions of the standard it supports, and the frontend or user can chose. I guess that would work! :) actually- this idea is growing on me. it prevents the need to fork sane and do a separate 1.1 branch- we can require that the new frame types be protected by '--standard=1.1', and that well-known option can have a warning, and front-ends that dont support certain minor versions of the standard can hide them, and front-ends that do can enable them by default. no bump in the SONAME keeps external backends happy. there must be some downsides, however- opinions? seems fine to me, this would surely help older frontends. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
On Fri, 21 Dec 2007 10:06:09 -0500 m. allan noah kitno455 at gmail.com wrote: actually- this idea is growing on me. it prevents the need to fork sane and do a separate 1.1 branch- we can require that the new frame types be protected by '--standard=1.1', and that well-known option can have a warning, and front-ends that dont support certain minor versions of the standard can hide them, and front-ends that do can enable them by default. no bump in the SONAME keeps external backends happy. there must be some downsides, however- opinions? mm. a frontend could display this as a gadget and thus the user could enable a standard the frontend does not support? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
On Dec 21, 2007 12:13 PM, Alessandro Zummo azummo-lists at towertech.it wrote: On Fri, 21 Dec 2007 10:06:09 -0500 m. allan noah kitno455 at gmail.com wrote: actually- this idea is growing on me. it prevents the need to fork sane and do a separate 1.1 branch- we can require that the new frame types be protected by '--standard=1.1', and that well-known option can have a warning, and front-ends that dont support certain minor versions of the standard can hide them, and front-ends that do can enable them by default. no bump in the SONAME keeps external backends happy. there must be some downsides, however- opinions? mm. a frontend could display this as a gadget and thus the user could enable a standard the frontend does not support? yes- This is one advantage of a new standard version with a new SONAME, frontends could be build against it as-is, but frontend authors get more warning that something has changed. allan -- The truth is an offense, but not a sin
[sane-devel] The future of the SANE-Standard
On Fri, 21 Dec 2007 09:47:13 -0500 m. allan noah kitno455 at gmail.com wrote: if the dll backend had no mechanism to determine existence of the call beforehand, i assume it would segfault. besides, this assumes that all callers will link against the dll backend exclusively- every backend exports the same interface, so that frontends can link against them directly. i would not want to break that. you mean using -lsane-backend instead of -lsane, right? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
On 21.12.2007 15:33, Alessandro Zummo wrote: On Fri, 21 Dec 2007 09:12:56 -0500 m. allan noah kitno455 at gmail.com wrote: well, i wanted to minimize the changes to front-ends, other than dropping unknown frame types. also, this sets up a precedent for backends needing to have 'modes' where they support historical versions of the sane standard. in this case, that is not a problem, but in the future, it might be. are you proposing that we update every backend in sane with this function- because they are all going to get their minor version number bumped to 1, to match their new sonames... i'm just thinking about it, so it is not a proposal at this time. i have not yet checked the matter in the sane source but, if we add the api call to dll.c and not in the backend, what will happen? a) segfault b) SANE_STATUS_NOT_SUPPORTED ? I'd prefer such an enabler function to an enabler option. The latter would cause lots of questions from naive users :) Perhaps I missed something -- but reading the function init() in backend/dll.c, I think that the dll backend returns SANE_STATUS_NOT_SUPPORTED for functions which do not exist in the real backend. The BeOS implementation is the only exception I could see, but that should be easy to fix. So, for dynanically linked backends, it should be fine to use a new enabler function, which does not exist in 1.0.x backends. Unfortunately, an enabler function, which is optional for backends, would not work for statically linked backends. But are these used anywhere? In other words: Couldn't we simply drop static linkage? Abel
[sane-devel] The future of the SANE-Standard
On Fri, 21 Dec 2007 19:27:57 +0100 abel deuring adeuring at gmx.net wrote: So, for dynanically linked backends, it should be fine to use a new enabler function, which does not exist in 1.0.x backends. Unfortunately, an enabler function, which is optional for backends, would not work for statically linked backends. But are these used anywhere? In other words: Couldn't we simply drop static linkage? only if really isn't used anywhere. we might see if we can use the first parameter of sane_init to pass some special value to the backend. sane_init(SANE_Int * version_code, SANE_Auth_Callback authorize) current frontends will pass either NULL here or a ptr to a SANE_Int . this ptr could be either zero or uninitialized (garbage). we might use it in some way. or maybe the authorize callback could be used. the backend could call it with some magic value in resource/user/password. other options? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
Alessandro Zummo azummo-lists at towertech.it wrote: other options? Just adding the new frames options and leave it at that, like planned ? What you're proposing is just perverting the API and an inacceptable change in the behaviour of the current API. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] The future of the SANE-Standard
On Fri, 21 Dec 2007 19:47:06 +0100 Julien BLACHE jb at jblache.org wrote: Alessandro Zummo azummo-lists at towertech.it wrote: other options? Just adding the new frames options and leave it at that, like planned ? What you're proposing is just perverting the API and an inacceptable change in the behaviour of the current API. I would like to avoid exposing the new frame types to unaware frontends. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
On Fri, 21 Dec 2007 19:51:04 +0100 Alessandro Zummo azummo-lists at towertech.it wrote: Just adding the new frames options and leave it at that, like planned ? What you're proposing is just perverting the API and an inacceptable change in the behaviour of the current API. I would like to avoid exposing the new frame types to unaware frontends. replying to myself, that means I'm gone banana :) the options are: a) add types and options, with little risk for older backends. b) add and protect via current api mangling c) add and protect via new api. option c means that some linking combinations will not work, like linking an 1.1 aware frontend with a non 1.1 aware backend. I guess this shouldn't happen. If it happens, it's fixable by adding a few lines of code to the backend. at this point, I never heard of any frontend that does directly linking of a backend. while I favour option c , I'm not against any of them. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
On Dec 21, 2007 2:36 PM, Alessandro Zummo azummo-lists at towertech.it wrote: On Fri, 21 Dec 2007 19:51:04 +0100 Alessandro Zummo azummo-lists at towertech.it wrote: Just adding the new frames options and leave it at that, like planned ? What you're proposing is just perverting the API and an inacceptable change in the behaviour of the current API. I would like to avoid exposing the new frame types to unaware frontends. replying to myself, that means I'm gone banana :) the options are: a) add types and options, with little risk for older backends. b) add and protect via current api mangling c) add and protect via new api. option c means that some linking combinations will not work, like linking an 1.1 aware frontend with a non 1.1 aware backend. I guess this shouldn't happen. If it happens, it's fixable by adding a few lines of code to the backend. at this point, I never heard of any frontend that does directly linking of a backend. while I favour option c , I'm not against any of them. if i understand your list, there is a 4th option- add and _inform_ by SONAME/version# change. Bumping the SONAME seems to be the only way to make the outside world aware that they should inspect their code for compatibility, but even if they do not, it will still work, since these new frame types will not be the default case. It also prevents us from having to do any modifications to the dozens of existing backends that wont have the new frame types or options. (unlike b and c). allan -- The truth is an offense, but not a sin
[sane-devel] The future of the SANE-Standard
On Fri, 21 Dec 2007 14:45:25 -0500 m. allan noah kitno455 at gmail.com wrote: if i understand your list, there is a 4th option- add and _inform_ by SONAME/version# change. Bumping the SONAME seems to be the only way to make the outside world aware that they should inspect their code for compatibility, but even if they do not, it will still work, since these new frame types will not be the default case. It also prevents us from having to do any modifications to the dozens of existing backends that wont have the new frame types or options. (unlike b and c). well, yes, that works too. I the hope that the outside world will care :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
m. allan noah kitno455 at gmail.com wrote: Hi, if i understand your list, there is a 4th option- add and _inform_ by SONAME/version# change. If we can avoid it, we should really avoid it. Though as you note it's the proper course of action if the changes are important enough that things could break. Bumping the SONAME seems to be the only way to make the outside world aware that they should inspect their code for compatibility, but even if they do not, it will still work, since these new frame types will not be the default case. It also prevents us from having to do any modifications to the dozens of existing backends that wont have the new frame types or options. (unlike b and c). I think bumping the SONAME is going to have interesting effects wrt proprietary backends. Now that I think about it ... : JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] The future of the SANE-Standard
On Dec 21, 2007 3:19 PM, Julien BLACHE jb at jblache.org wrote: m. allan noah kitno455 at gmail.com wrote: Hi, if i understand your list, there is a 4th option- add and _inform_ by SONAME/version# change. If we can avoid it, we should really avoid it. Though as you note it's the proper course of action if the changes are important enough that things could break. Bumping the SONAME seems to be the only way to make the outside world aware that they should inspect their code for compatibility, but even if they do not, it will still work, since these new frame types will not be the default case. It also prevents us from having to do any modifications to the dozens of existing backends that wont have the new frame types or options. (unlike b and c). I think bumping the SONAME is going to have interesting effects wrt proprietary backends. Now that I think about it ... : yes- i've thought of that, and that is part of the reason i have been talking about possibly adding/clarifying some additional well-known options while we have their attention. Particularly WRT ADF option handling and the various MFP's out there. allan -- The truth is an offense, but not a sin
[sane-devel] The future of the SANE-Standard
Am Freitag, den 21.12.2007, 20:53 +0100 schrieb Alessandro Zummo: On Fri, 21 Dec 2007 14:45:25 -0500 m. allan noah kitno455 at gmail.com wrote: if i understand your list, there is a 4th option- add and _inform_ by SONAME/version# change. Bumping the SONAME seems to be the only way to make the outside world aware that they should inspect their code for compatibility, but even if they do not, it will still work, since these new frame types will not be the default case. It also prevents us from having to do any modifications to the dozens of existing backends that wont have the new frame types or options. (unlike b and c). well, yes, that works too. I the hope that the outside world will care :) In the moment I would bet on the outside world. At least the active part of the inside world does not seem to care ;) The proposals/discussions I read in the last hours are worse than everything that I expected when I predicted the chaos. Only adding some new frame types and now discussing to add new api functions. And letting the sane standard at version 1.x. while changing the api. Did anyone of you read the SANE-standard 1.0? Did anyone of you ever created a standard? I don`t know what I can say or do. My hope is that someone who knows what he does gets active and directs this disaster into the right way... or stopps all this. In the meanwhile I will look for a new project or hobby ... this one seems to die. (But I still pray for it). Best regards Oliver
[sane-devel] The future of the SANE-Standard
On Fri, 21 Dec 2007 22:12:03 +0100 Oliver Rauch Oliver.Rauch at rauch-domain.de wrote: In the moment I would bet on the outside world. At least the active part of the inside world does not seem to care ;) The proposals/discussions I read in the last hours are worse than everything that I expected when I predicted the chaos. Only adding some new frame types and now discussing to add new api functions. And letting the sane standard at version 1.x. while changing the api. don't worry, we are just discussing it. And it seems that no api function will be added nor modified. we are very concerned toward compatibility and existing frontends. in particular, we are trying to do thing in a way that allows xsane to work without modifications. if it wasn't for those concerns, we would just have bumped sane to 1.1 AND added new APIs. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
On Dec 21, 2007 4:12 PM, Oliver Rauch Oliver.Rauch at rauch-domain.de wrote: Am Freitag, den 21.12.2007, 20:53 +0100 schrieb Alessandro Zummo: On Fri, 21 Dec 2007 14:45:25 -0500 m. allan noah kitno455 at gmail.com wrote: if i understand your list, there is a 4th option- add and _inform_ by SONAME/version# change. Bumping the SONAME seems to be the only way to make the outside world aware that they should inspect their code for compatibility, but even if they do not, it will still work, since these new frame types will not be the default case. It also prevents us from having to do any modifications to the dozens of existing backends that wont have the new frame types or options. (unlike b and c). well, yes, that works too. I the hope that the outside world will care :) In the moment I would bet on the outside world. At least the active part of the inside world does not seem to care ;) The proposals/discussions I read in the last hours are worse than everything that I expected when I predicted the chaos. Only adding some new frame types and now discussing to add new api functions. And letting the sane standard at version 1.x. while changing the api. and again- if you would reread the thread, you will see that it is just a discussion, and that we are in the process of shooting it down :) Did anyone of you read the SANE-standard 1.0? Did anyone of you ever created a standard? and have you ever worked in a team? people have to explore the possibilites to be sure they are applying their efforts in the most efficient fashion. In the end, we will arrive at a rough consensus, AND running code. I don`t know what I can say or do. My hope is that someone who knows what he does gets active and directs this disaster into the right way... or stopps all this. In the meanwhile I will look for a new project or hobby ... this one seems to die. (But I still pray for it). you want to know what you can say or do? 1. You can stop insisting that SANE2 is the only mechanism by which sane can improve. 2. You can acknowledge that we are attempting to find a compromise that suits your needs AND ours. 3. You can ENGAGE in this discussion instead of threatening to 'quit the project'. allan -- The truth is an offense, but not a sin
[sane-devel] The future of the SANE-Standard
Am Freitag, den 21.12.2007, 22:21 +0100 schrieb Alessandro Zummo: we are very concerned toward compatibility and existing frontends. in particular, we are trying to do thing in a way that allows xsane to work without modifications. if it wasn't for those concerns, we would just have bumped sane to 1.1 AND added new APIs. Hello Alessandro, the problem I see here is that the discussion is not based on the needed knowledge. When you change the API of SANE then you have to call it SANE-2. This is defined in the SANE-1-standard. So please, everyone who takes part in this discussion: read the SANE-1 standard at first and when you want to discuss if new features should be part of SANE-1 or SANE-2 then it would be a good idea to also read the SANE-2 proposal. The major problem seems to be that almost all people that know the SANE-1 standard and know what hasto be done to change a standard are not active here any more. Most of the people take part in this discussion did not prepare good enough for this discussion. How do you want to make good proposals when you do not know the relvant things? Best regards Oliver
[sane-devel] The future of the SANE-Standard
On Fri, 21 Dec 2007 22:46:18 +0100 Oliver Rauch Oliver.Rauch at rauch-domain.de wrote: How do you want to make good proposals when you do not know the relvant things? I think the relevant thing is this one: 3.2 Image Data Format Arguably the most important aspect of an image acquisition system is how images are represented. The SANE approach is to define a simple yet powerful representation that is sufficient for vast majority of applications and devices. While the representation is simple, the interface has been defined carefully to allow extending it in the future without breaking backwards compatibility. Thus, it will be possible to accommodate future applications or devices that were not anticipated at the time this standard was created. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
Oliver Rauch Oliver.Rauch at rauch-domain.de wrote: Hi, My hope is that someone who knows what he does gets active and directs this disaster into the right way... or stopps all this. Nothing has been committed to CVS yet, no code has even been written, and 1.0.19 will go first. So there's still a comfortable margin. That said, bumping the soname is going to be a big deal and I'm not in favor of doing that unless there's a good reason to do so. The frame types addition can be done without changing the API. Adding new functions to the API can be done without bumping the soname (only a minor version increment, major stays at 1, so soname remains libsane.so.1). Anything else, you'd better have a GOOD reason for changing the API (or ABI, be careful) and bumping the soname. Because it's sure going to be a mess. If it's for convergence to SANE2, then sure, go for it. But not now. Bottom line: bumping the soname is not warranted for the frame types addition. Going to 1.1.x is enough. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] The future of the SANE-Standard
On Fri, 21 Dec 2007 22:55:01 +0100 Julien BLACHE jb at jblache.org wrote: The frame types addition can be done without changing the API. Adding new functions to the API can be done without bumping the soname (only a minor version increment, major stays at 1, so soname remains libsane.so.1). ack. Bottom line: bumping the soname is not warranted for the frame types addition. Going to 1.1.x is enough. ack. just my two cents :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] The future of the SANE-Standard
On Dec 21, 2007 4:55 PM, Julien BLACHE jb at jblache.org wrote: Oliver Rauch Oliver.Rauch at rauch-domain.de wrote: Hi, My hope is that someone who knows what he does gets active and directs this disaster into the right way... or stopps all this. Nothing has been committed to CVS yet, no code has even been written, and 1.0.19 will go first. So there's still a comfortable margin. That said, bumping the soname is going to be a big deal and I'm not in favor of doing that unless there's a good reason to do so. The frame types addition can be done without changing the API. Adding new functions to the API can be done without bumping the soname (only a minor version increment, major stays at 1, so soname remains libsane.so.1). Anything else, you'd better have a GOOD reason for changing the API (or ABI, be careful) and bumping the soname. Because it's sure going to be a mess. If it's for convergence to SANE2, then sure, go for it. But not now. Bottom line: bumping the soname is not warranted for the frame types addition. Going to 1.1.x is enough. the problem that oliver is pointing out is this: 4.1 Version Control 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. Boy, this is getting hairy, because it requires you to define 'incompatible'. i daresay that we would each define it a bit differently in this case. allan -- The truth is an offense, but not a sin
[sane-devel] The future of the SANE-Standard
m. allan noah kitno455 at gmail.com wrote: Hi, 4.1 Version Control 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. Boy, this is getting hairy, because it requires you to define 'incompatible'. i daresay that we would each define it a bit differently in this case. There's no compatibility problem as long as you're extending the API and not modifying the current API. Which is exactly what is to be done to add new frame types. Anything else is potentially a problem, though. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] The future of the SANE-Standard
m. allan noah kitno455 at gmail.com wrote: Hi, and a second reply to your mail- i too would like to avoid the soname bump, but we must acknowledge that we are changing both the API and the ABI, even if only slightly, and creating a potential for changing vs. extending. Changing is unsafe without a soname bump, extending is, as long as you don't break the ABI (e.g. adding a member to a struct is a no-no, adding a member to an enum is pretty much OK if you don't change the values of the other members). Provided the spec is well written enough, but SANE 1 is. Frontend bugs will need to be fixed if they arise. seems to be the fastest way to extend sane, while still making the world aware, and not requiring us to modify lots of stale backends to the as-yet unfinished sane2 spec. If converting a backend to SANE2 can be done in a week-end as Oliver suggested, I can't see why we could not convert existing backends, even if unmaintained. We couldn't test them, which is a problem. To remedy that (sort of) we can sort the backends by maintained/unmaintained status at the source level (aka 2 distincts directories). [Oh, as a side note, I'd love to have that as a runtime feature too, being able to identify maintained/unmaintained/experimental/external/proprietary backends] So 1. we don't loose old backends, 2. anybody with the hardware can test them, fix them as needed and report back. Anyway we won't be able to roll out SANE2 overnight, and there will be a lengthy beta phase. That could leave enough time to get some of the older backends tested fixed. Now, there have been a number of discussions on this topic already. Oliver has valid points, others have too. Every time this discussion happens, it all goes back to the status quo. Maybe this time we will be able to actually get something done, otherwise I'm afraid SANE might be doomed as it would mean it's just unable to evolve. And that would really be sad. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] The future of the SANE-Standard
Oliver Rauch Oliver.Rauch at rauch-domain.de wrote: Hi, The major problem seems to be that almost all people that know the SANE-1 standard and know what hasto be done to change a standard are not active here any more. Most of the people take part in this discussion did not prepare good enough for this discussion. It's definitely a problem. A big one. But not one that can be fixed, unfortunately. Otherwise those people would have joined the discussion already in fear of the newbies breaking everything... SANE2 has been a dead end for years and during this time the people behind SANE and SANE2 just disappeared into the ether for whatever reason. We're not going to bring them back, because it's just not possible for most of them (we may recover some of them, though, eventually, like Henning maybe). I haven't had a look at SANE2 in years. I'll try to take a look at it as soon as possible. I am definitely interested in going forward with SANE (as a project) and SANE2. If SANE doesn't evolve I really don't see how we're going to have working scanners on non-Windows platforms. I don't see another team/project stepping up to rewrite something, given the low interest I see in SANE from other people (interestingly the desktop people seem to have next to no interest in SANE). JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
