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

[Olaf Meeuwissen]

"m. allan noah" <kitno455 at gmail.com> writes:

>> Julien BLACHE wrote:
>>> stef <stef.dev at free.fr> wrote:
>>>>      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.

Distributions will face a bear of a problem here because they would
need to get updated versions of _all_ frontends they ship before their
next scheduled release.  Without a soname change there is no sane way
that they could have some frontends using SANE 1.0 and some SANE 1.1
installed next to each other.

>>> The problem is binary-level backward compatibility, not source-level
>>> backward compatibility.

Introducing SANE_STATUS_WARMING_UP and having sane_start() return it
is much worse.  It changes the behaviour of the function.

>>> 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.

Imagine what you would have to do to get a mish-mash of 1.0 and 1.1
backends working with a mish-mash of 1.0 and 1.1 frontends.  Next,
imagine what happens when you install an external (proprietary, even)
frontend or backend. Finally, consider all that in the light of the
benefit of the changes you get with 1.1.

> 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?)

If there were a lot of backend fixes and extensions that do not use or
depend on the 1.1 changes, there might be something to say for another
1.0.x release with the offending 1.1 stuff backed out.

> 2. Release this as sane 2.0.

If there were few other changes besides those for the 1.1 stuff, a
soversion bump is probably the best way to move forward.  However,
considering the scope of the changes, 2.0 feels a little like an
overstatement and we could consider some extra, non-controversial!,
API-breaking changes.  Are there any ;-)

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

Which might just have happened :-|

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

My vote would be for #1 first (see above for conditions) and for #2
next.

Hope this helps,
-- 
Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962               Help support software freedom
                 http://www.fsf.org/jf?referrer=1962