[sane-devel] Patch to make XSane work with SANE 1.1
stef.dev at free.fr
Mon Oct 13 20:10:51 UTC 2008
Le Monday 13 October 2008 19:55:30 m. allan noah, vous avez écrit :
> 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.
> ret = sane_start()
> 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
> 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
> I personally hate to remove working code (#1), and fear the delay of a
> redesign (#3), so I vote for #2.
> "The truth is an offense, but not a sin"
I'm also in favor of #2.
More information about the sane-devel