[sane-devel] The future of the SANE-Standard

[abel deuring]

On 21.12.2007 15:33, Alessandro Zummo wrote:
> On Fri, 21 Dec 2007 09:12:56 -0500
> "m. allan noah" <kitno455 at gmail.com> wrote:
> 
>> well, i wanted to minimize the changes to front-ends, other than
>> dropping unknown frame types. also, this sets up a precedent for
>> backends needing to have 'modes' where they support historical
>> versions of the sane standard. in this case, that is not a problem,
>> but in the future, it might be.
>>
>> are you proposing that we update every backend in sane with this
>> function- because they are all going to get their minor version number
>> bumped to 1, to match their new sonames...
> 
>  i'm just thinking about it, so it is not a proposal at this time.
> 
>  i have not yet checked the matter in the sane source but, if we add 
>  the api call to dll.c and not in the backend, what will happen?
> 
>   a) segfault
>   b) SANE_STATUS_NOT_SUPPORTED
> 
>  ?

I'd prefer such an "enabler function" to an "enabler option". The latter
would cause lots of questions from naive users :)

Perhaps I missed something -- but reading the function init() in
backend/dll.c, I think that the dll backend returns
SANE_STATUS_NOT_SUPPORTED for functions which do not exist in the "real"
backend. The BeOS implementation is the only exception I could see, but
that should be easy to fix.

So, for dynanically linked backends, it should be fine to use a new
"enabler function", which does not exist in 1.0.x backends.

Unfortunately, an "enabler function", which is optional for backends,
would not work for statically linked backends. But are these used
anywhere? In other words: Couldn't we simply drop static linkage?

Abel