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"