[sane-devel] The future of the SANE-Standard
m. allan noah
kitno455 at gmail.com
Fri Dec 21 14:47:13 UTC 2007
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.
"The truth is an offense, but not a sin"
More information about the sane-devel