[sane-devel] Sane API

[Ralph Little]

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