python parser for dotconf file

[Hynek Hanke]

>     So I think that the only reasonable way to modify them is to read
>     all such options first, construct the list, then modify it and write
>     back. I don't think it makes sense to modify them separately.
>
> Hmmm, so can we expect to get a list of dotConfObject(s) from the 
> programmer
I think in case of AddModule, this should be only one
dotConfObject which is a list. The object should know,
that its first level of list is being represented by multiple
option lines.

In case these lines are scatered around the config file
and it is necessary to modify them, I'd say that the all
the corresponding AddModule lines in the output
should be written to the configuration file at the place
where the first AddModule line occurs and the other
original AddModule lines that do not immediatelly
follow should be commented out or deleted.
> I see the following USE Cases:
>
>    1. Add a new parameter
>          1. Ask the programmer to submit a parameter along with a list
>             of values through a dotConfObject. pyDotconf searches for
>             an existing entry for the parameter.
>          2. If(entry_exists) return error
>          3. else add the parameter to the dot.conf file
>
Yes.
>
>    1. Delete parameter entry - It deletes every instance of a specific
>       parameter in the dotconf file
>
I'd say 'delete' or 'comment out'. But maybe you meant to include commenting
out into editing -- that makes sense as well. I do not have any 
preference for
one of these two, I just think it should be possible to comment out.
>
>    1. Edit an existing parameter
>          1. Get the list of dotConfObject through which he/she c
>             progan find the value of each parameter
>
>          1. Modify this list and send back to pyDotconf.
>          2. pyDotconf will delete(2) all declarations of the parameter
>             in the conf file (even if they are spread across the file
>
>          1. add the fresh entries using add(1) parameter internally
>
Yes.
>
>    1. The programmer will be able to specify for each parameter item
>       whether it is commented or uncommented in the file through the
>       dotConfObject
>
> The present implementation of the parser (I think) correctly ignores 
> the commentary for a parameter. I ran the code for AddModule and it 
> does not pick up the commentary at all. I will look into the 
> implications of what you have said in greater details and post back 
> soon enough.
I think it can only be done heuristically, so I think we should avoid it
if necessary when writing the config file.
> Well OLPC will have certain default speech synthesis settings for the 
> laptop, and we would like to preserve those settings. Also we expect 
> other developers in the community to use speechd-api and would like 
> that the default speech-dispatcher settings for OLPC be applied to 
> each client that makes a connection. So we will achieve that by 
> directly modifying the speechd.conf file. Most of the programming is 
> done in python, hence, the need for a library to modify the dot.conf 
> file in python :).
I don't understand this very well. So the python library is used for initial
speechd configuration? Or is some reconfiguration on-the-fly being done?
What do you mean by preserving speech synthesis settings? What kind of
settings?
> Thank you for your inputs, I hope we are able to finalize the 
> requirements from pyDotconf soon. Once that is done, I will make the 
> necessary changes and release it for use.
That sounds great, thank you.

With regards,
Hynek