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

[m. allan noah]

On Dec 21, 2007 9:33 AM, Alessandro Zummo <azummo-lists at towertech.it> 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
>
>  ?
>
>  if b, we would not need to update the backends. if a) then it
>  is not the way to go.
>
>  I do not like changing every backend. but if we can change little
>  in dll/"real" 1.1 backends that would be fine.
>

if the dll backend had no mechanism to determine existence of the call
beforehand, i assume it would segfault. besides, this assumes that all
callers will link against the dll backend exclusively- every backend
exports the same interface, so that frontends can link against them
directly. i would not want to break that.

so- if we want to protect front-ends from the updated backends- the
only mechanism we have is a well-known option. instead of a boolean,
how about a string list- then a backend can report what versions of
the standard it supports, and the frontend or user can chose.

allan

-- 
"The truth is an offense, but not a sin"