[sane-devel] Sane API

[Thierry HUCHARD]

Hi Alexander,

I didn't feel any animosity, just an exchange of ideas.
I don't have time to answer, I'm on an important bug. but I won't miss 
it tonight :)

Thierry

Le 2020-10-20 17:04, Ralph Little a écrit :
> 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