Le Monday 23 June 2008 22:06:30 m. allan noah, vous avez ?crit?: > On Mon, Jun 23, 2008 at 3:36 PM, stef <stef.dev at free.fr> wrote: > > Le Thursday 19 June 2008 15:36:59 m. allan noah, vous avez ?crit : > >> pretty good, but i have two comments: > >> > >> 1. i think calling the struct SANE_Config instead of something with > >> sanei in it, makes it look too much like something that should be in > >> the SANE standard, instead of the internal-use function that it is. > >> > >> 2. some backends seem to have dozens of options, that struct is going > >> to become quite large if it is extending to hold everything. does it > >> instead make more sense for the callback to be run for each line > >> extracted from the file, with a flag indicating that it was an option > >> instead of an attach line? > >> > >> allan > > > > Hello, > > > > here's a new take at config option parsing. The struct is now > > called SANEI_Config, and holds an array of SANE_Option_Descriptor and an > > array of placeholder for the values of the options. > > brilliant. enables us to reuse lots of code, and keep a familiar > interface. bravo. > > > To parse options, a backend first > > creates a list of the options it wants using SANE_Option_Descriptor. > > great. > > > Then it calls sanei_configure_initialize() which creates the > > placeholders. When the SANEI_Config is ready, the backend calls > > sanei_configure_attach() which opens the configuration, parse it > > according to the given descriptors. Whenever a line no recognized as an > > option is met, the > > sanei_configure_attach() calls the backend provided > > (*attach)(SANEI_Config *, char *devname) attach function. This backend > > specific function calls the usb/scsi/parport attach functions allready > > provided by sanei library. As a parameter it has the currently parsed > > options in the config struct and so may use them during the attach. A > > sanei_configure_get_value() helper is given to access the values of the > > options. > > Once parsing is done, there is a sanei_configure_dispose() > > function to release allocated ressources. > > i would rather that the backend provided the placeholder memory if > possible, for two reasons: 1. to keep all the memory allocations in > one place, 2. so that the placeholders can be pre-loaded with default > values by the backend. > > > By doing this way, configuration is parsed only with the options > > the backend needs. The existing sanei_check_value() may be reused to > > check if constraints are respected. Only a couple options that need a > > complex syntax couldn't be handled right now (such as 'calibrate > > /path/name port' from canon_pp) but could be handled by a > > SANE_TYPE_STRING_LIST to be created. > > > > The appended patch currently only manage SANE_TYPE_STRING options > > and as been tested with a modified rts8891 backend. > > this sounds quite good- thank you very much for taking on the task! > > allan > -- > "The truth is an offense, but not a sin"
Hello, here's the patch modified like you suggest. Now both descriptors and placeholders are given by the backend. There is no need for a free'ing function anymore. Regards, Stef -------------- next part -------------- A non-text attachment was scrubbed... Name: proposal.patch.gz Type: application/x-gzip Size: 4750 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080625/411eb2c4/attachment.bin