[sane-devel] Sane Release 1.1.0 ?
olaf.meeuwissen at avasys.jp
Fri Nov 7 07:08:12 UTC 2008
Julien BLACHE <jb at jblache.org> writes:
> "m. allan noah" <kitno455 at gmail.com> wrote:
>> My biggest concerns are those raised by Olaf- how do the two versions
>> coexist. I will bet you that the solution we come up with will be
>> EXACTLY the same, whether we add your new function or not. So, i want
> No, if we go and add an optional status function, this problem does
> not exist. I covered that in my mail.
> If we go that route and do a 1.1, the dll backend can load *.so.1* and
> be done with it. If it's a 1.1 backend, it will have the function
> defined, nothing more to do, if it's a 1.0 backend it won't have it
> and dll wires up a stub instead. All backends in 1.1 define the
> function, a stub is used for all the backends that are unmaintained
This would entail adding two sane_status() implementations to stubs.c.
One that returns SANE_STATUS_UNSUPPORTED and is the default, the other
forwards to the backend's implementation just like all the other SANE
API stub entries do already. Every backend that wants to provide its
own sane_status() defines the appropriate preprocessor symbol and
implements the call.
The dll backend checks whether it found sane_BE_status() in a backend
and calls that if found, SANE_STATUS_UNSUPPORTED otherwise.
> There, done, no problem. Total backward compatibility with anything
> built against 1.0. No change in the behaviour of the current API
> calls. Some work to do on saned/net as the new call needs to added and
> the version check needs to be extended a bit (1.1 client cannot talk
> to a 1.0 saned or needs to wire up a stub call for the new call). No
> big issue, takes time and testing.
Oops, almost forgot about saned.
> Now, speaking of a proper 2.0 release, this has all been discussed
> already. I think the best thing we came up with was a sane1 compat
> backend based on dll that does the conversion and stuff. That and
> installing the backends under /usr/lib/sane2 (avoids dupes - note that
> you can restrict dll to *.so.2* and sane1 to *.so.1* instead). Some
> work on saned/net required as usual, version check needs some work and
> testing to ensure saned and the client reject the other version as
> Makes no sense for such small changes.
Hope this helps,
Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962 Help support software freedom
More information about the sane-devel