"m. allan noah" <kitno455 at gmail.com> wrote: Hi,
> 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 today. 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. Plus: new status function frontends can use at any time (though the function can reply "sorry can't tell you now"), and in 2.0 we can separate API status (SANE_Retval or something) and hardware status (SANE_Status or something else). 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 needed. Makes no sense for such small changes. JB. -- Julien BLACHE <http://www.jblache.org> <jb at jblache.org> GPG KeyID 0xF5D65169