[sane-devel] Patch to make XSane work with SANE 1.1

[m. allan noah]

On Mon, Oct 13, 2008 at 11:45 AM, René Rebe <rene at exactcode.de> wrote:
> Hi,
>
> Julien BLACHE wrote:
>> stef <stef.dev at free.fr> wrote:
>>
>> Hi,
>>
>>
>>>      frontends will have to be changed to benefit from the improvements in the new SANE
>>> version. These changes are small, and the sane-frontends package give a sample
>>> implementation. Frontend developers will find help here if they need.
>>>
>>
>> The problem is binary-level backward compatibility, not source-level
>> backward compatibility.
>>
>> The issue is that upgrading SANE should not break frontends
>> silently. I'm pretty sure the sane_start() change will break not only
>> multi-page scans but also automated scripts.
>>
>> There's also the possibility to use a 1.1 backend with a 1.0
>> libsane, aka using a 1.1 backend with a 1.0 libsane-dll. That's
>> another variation on that same theme.
>>
> The light status will not break a frontend, just make it respond quickly
> with an condition. Actually I find a pop-up dialog in a UI program telling
> me "light warming up" more useful than a program that hangs for 30 seconds
> and does not even refresh the UI in this period of time. The user can
> then still
> make further changes to e.g. the scan settings and just re-click scan
> later. And
> a spinning progress indicator really is not too much of a deal for further
> improvement.
>
> Binary incompatible and breaking would be silently data corruption or
> no longer starting due to missing symbols etc.

pseudocode:

ret = sane_start()
if(ret){
  die("bad status");
}

that works in sane 1.0, and fails in sane 1.1, both with the original
binary, and with a new binary compiled against 1.1 headers. Thus, it
is both a source and a binary incompatibility, which calls for a
soversion bump. We knew this going in, yet some folks were very much
against the bump, so we split hairs, and tried to say it was not big
enough to matter. That was a foolish choice, which drove some
developers away. I take a great measure of personal responsibility for
that.

We have several choices as i see it:

1. Remove new status values and release sane 1.1. (do we need to
remove other things?)

2. Release this as sane 2.0.

3. Reopen the sane 2.0 discussion, and make more drastic changes to the API.

I personally hate to remove working code (#1), and fear the delay of a
redesign (#3), so I vote for #2.

allan
-- 
"The truth is an offense, but not a sin"