sane config files [was [sane-devel] Infrared channel]]

[Oliver Rauch]

Am Don, 2005-02-24 um 18.49 schrieb Julien BLACHE:
> "m. allan noah" <anoah@pfeiffer.edu> wrote:
> 
> > let me ask this: how many of the config files that must be kept are
> > kept because they have scanner-specific information in them, as
> > opposed to backend-specific information?
> >
> > ie: how many times does a conf file say:
> >
> > 'for any scanners that use this backend, enable feature x"
> >
> > v/s
> >
> > 'for this particular model of scanner, enable feature x'
> >
> > v/s
> >
> > 'for this particular serial number, enable feature x'
> >
> > the reason i ask is that it would seem, based on the name, that only
> > the first example really belongs in 'backend.conf', where the others
> > belong in a per-model or per-SN file?
> 
> Don't you think that at least item 1 and 2 can be detected by the
> backend ? (the serial number might not be accessible by the backend,
> sure). There's still the possibility that a vendor will slightly
> modify the hardware and not anything else, making it impossible to
> guess which version of the hardware we're talking to.
> 
> If we cannot get rid of the config files (there's some experience like
> the same product ID applying to slightly different hardware), we can
> at least have a look at them as they are now, see if there are options
> that can be removed, and try to come up with a unified format.


When there are really some settings that need to be selected by the
user, why are these settings not implemented as a sane option, may be an
advanded sane option.

May be we need an additional flag to the existing ADVANCED flag, may be
a CONFIGURE flag. This way the backend would define what the user can
select and we already would have a configuration tool: the frontend.
The backend could save the last selected setting in its own
configuration file as a default option (although this also could be done
by the frontend).


Oliver