Hi, On 2020-10-20 1:41 a.m., Alexander Pevzner wrote: > On 10/20/20 11:18 AM, Michael Starr wrote: >> Guys guys, just calm down. This is for Linux, remember? > > Excuse me if I sound rude, I don't feel that and trying to be polite. > English is not my native language so I can miss some nuances. > Actually, I'm just trying to summarize things. > I detected no rudeness. Please continue as you were.
My initial posting has obviously ignited some passionate opinions and I think this is great! It is good that there seems to be an appetite to make some changes in an area that has become stagnant. ========== There have been a lot of ideas generated but I feel that we should coordinate them into something that we can make concrete progress on. Might I suggest that there are two broad options that we can implement either or both of: 1) Expand the current standard without changing the functional API itself. This would include enhancing the current set of recommended and mandatory options to address shortcomings that have been identified. IIRC, the standard drafts have mainly worked in this area. 2) Introduce a SANE 2 API which breaks compatibility with the current API to implement further features that are not satisfiable by just expanding the options. As has been mentioned, there are serious ramifications here and the implementation requires careful consideration because we would likely be stuck with it for some time. I think that some work in this area is timely since the plethora of machines supported by SANE has diversified somewhat from what was available many years ago: a) Most of what people use SANE for these days are multi-function devices and they come with their own particular foibles. b) We have new (fairly open) standards being introduced which offer the possibility that we could get wide compatibility in Linux. As a consequence, we have a number of machines supporting a number of different protocols provided by different backends. I have no doubt that manufacturers will coalesce their support around these new protocols because it makes economic sense for them to do so. Olaf, what do you feel would be the best way to formalise and discuss the proposals made by people in a more focused manner? There must have been a mechanism used in the past where proposals could be made, considered, perhaps voted on and added to the draft. I feel that we should embrace the current enthusiasm to make some changes. Perhaps we could set something up in GitLab? Cheers, Ralph
