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

[stef]

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

	Hello,

	I'm also in favor of #2.

Regards,
	Stef