[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
python parser for dotconf file
From: |
Hemant Goyal |
Subject: |
python parser for dotconf file |
Date: |
Mon, 7 Jul 2008 22:07:31 +0530 |
Hello Hynek,
I can't speak for DotConf, but Speech Dispatcher would surely benefit.
That's really good news, I am glad the code will prove useful to the speechd
community as well.
When there are several lines with the same parameter name,
> this should be treated as an enumeration or a list. For example
> ,,AddModule'' is used to construct a list of modules to be loaded.
>
> 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
that they wish to write to the file? I think the process for writing to the
dot.conf file must be crystal clear.
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
2. Delete parameter entry - It deletes every instance of a specific
parameter in the dotconf file
3. Edit an existing parameter
1. Get the list of dotConfObject through which he/she c progan find
the value of each parameter.
2. Modify this list and send back to pyDotconf.
3. pyDotconf will delete(2) all declarations of the parameter in the
conf file (even if they are spread across the file),
4. add the fresh entries using add(1) parameter internally.
4. The programmer will be able to specify for each parameter item whether
it is commented or uncommented in the file through the dotConfObject
> Like in this case:
> # DefaultModule is the module that will be used by default
> # DefaultModule "festival"
>
> We might make a rule that description comments are not
> allowed to begin with an option name in the configuration file.
> I would then change the config files in the next release of Speech
> Dispatcher so that this doesn't happen. Users however have
> older configuration files around, so this case should be handled
> somehow (I would say that if after stripping the comment character,
> the line doesn't make a proper dotconf syntax, it should be
> treated as a text coment).
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 have a question. Are you also planning to develop some tool
> to set the configuration option or are you going to use the python
> library for use in some OLPC-specific configuration mechanism?
> I'd like to learn more, because it looks interesting.
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 :).
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.
Best,
Hemant
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.freebsoft.org/pipermail/speechd/attachments/20080707/7c683cbc/attachment.htm