[sane-devel] SANE frozen in amber ?

Richard Ryniker ryniker at ryniker.ods.org
Fri Jun 12 16:45:07 UTC 2009


> 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.

A mandatory interface may return a status that indicates something is
"unknown" or "not applicable" and its client uses this to proceed in an
orderly way.  In the case of an optional interface, a client will eschew
use if any plausible alternative exists, in order to have a single logic
path.

The situation has potential to become exponentially complicated: two
paths to handle optional feature 1 (available in this backend, or not);
two additional paths for each of those cases to handle optional feature
2; two additional paths for each of the previous 4 to handle optional
feature 3, ...

The worst case is unlikely, but if scores of backends start to implement
"optional" features, the result could be chaos.

Certainly, there are places where indefinitely extensible interfaces have
value.  XML, ASN.1 are two examples that come immediately to mind.  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.



More information about the sane-devel mailing list