On Sat, Jun 13, 2009 at 8:42 AM, stef<stef.dev at free.fr> wrote: > Le vendredi 12 juin 2009 19:52:57 m. allan noah, vous avez ?crit : >> On Fri, Jun 12, 2009 at 12:45 PM, Richard >> >> Ryniker<ryniker at ryniker.ods.org> wrote: >> >> a frontend that asks for new, unsupported features, will simply >> >> get an appropriate error code. >> > >> > Allen Noah, earlier in this thread (Thu Jun 11 19:08:28 UTC 2009) alluded >> > >> > to the problem with this approach when he wrote: >> >>bah- then no front-end will use it, since it is not guaranteed to be >> >>there. >> >> <snip> >> >> > I believe SANE, like many other applications, will find it better to >> > change its API in infrequent, discrete steps than to follow a "continuous >> > change is permitted" strategy. >> >> Well, you can't get much more infrequent API changes than SANE :) >> >> Seriously, we have to bump the major number on the soversion to do any >> changes. The only real question is what do we do with all the >> unmaintained backends? >> >> 1: drag them along via modification >> 2: leave them behind and make the frontends link against sane1 and sane2 >> 3: leave them behind and use a sane-compat meta-backend to make them >> appear to have the sane2 api >> 4: make our API modifications small enough that old backends will be >> forward compatible >> >> Note that all 4 of these options are easier for the programmer if the >> API changes are kept small. Are there any other choices? >> >> allan > > ? ? ? ?Hello, > > ? ? ? ?maybe deciding first on what features we want to bring in would help > us to > choose. Once we know what to add, it should be easier to plan how to do it.
We already tried that. It is called the sane 2 draft spec, and its been sitting on the server for years. IMHO, we should not start another round of open-ended dreaming. We must keep in mind what is possible, given our limited resources. That is why I started from the 'how' instead of 'what' perspective. allan -- "The truth is an offense, but not a sin"
