On Tue, Mar 11, 2003 at 12:05:35PM +0100, Michael Bell wrote:>
I think it is a good idea to restart here again because every interface can be configured in a different way. So what do you think about the following (I use ca as an example and OPENCADIR/etc/ is /etc/openca in debian):
1. OPENCADIR/etc/servers/ca.conf is the today's configuration
2. OPENCADIR/etc/servers/ca.conf.template which is a ca.conf but with not replaced country
2. OPENCADIR/etc/servers.ca.xml is the future's configuration if we switch to XML
3. we include in ca.xml a path like this openca/software_config/
4. in this section we build a list:
<option>
<name>country</name>
<value>DE</value>
</option>
We can parse XML really easy so it is no problem to load and use these options.
5. we build a script which reads the original ca.conf.template and create the new ca.conf
You mean it tages ca.xml + ca.conf.template and outputs ca.conf?
Yes and in the future we take ca.xml.template and ca.xml and output ca.xml. Sounds stupid? Ok, I will try to explain it.
We use a structure in our xml-files that makes it possible to merge all xml files of a webinterface into one single file. The result is ca.xml which looks like this:
<openca> <software_config> <prefix>#</prefix> <suffix>#</suffix> <option>...</option> ... </software_config> </openca>
The configuration is placed in <configuration>...</configuration>. You must only check that software_config doesn't include some keywords with the correct prefix and suffix.
6. we create a function which can translate files (perhaps we include it to OpenCA::TRIStrateCGI)... I am not really sure on this last issue, do you plan to have static translation of the files, and save the results somewhere on disk, or do you plan to have dynamic translation, and translate on every load?
Alternatively (if thats not enough options already), you could go somewhere inbetween, ie translate the files and cache them somewhere.
I think a dynamical translation is ok for the first time. After a first time we can implement a cache directory in var/tmp/interface_name/. I think we can start with some practical aspects:
1. we need an additional function in OpenCA::TRIStateCGI - any recommendations for a name (e.g. getConfiguredData)?
2. I like to use XML:Twig in OpenCA::TRIStateCGI - any arguments against this module?
3. Where should we place the script who performs the translation? etc/ is normally the wrong place but every adminstrator find the script if we place it there. I have no idea what is the best way. Brian, you are a packager - what do think and which guidelines does debian have in this case?
Michael -- ------------------------------------------------------------------- Michael Bell Email (private): [EMAIL PROTECTED] Rechenzentrum - Datacenter Email: [EMAIL PROTECTED] Humboldt-University of Berlin Tel.: +49 (0)30-2093 2482 Unter den Linden 6 Fax: +49 (0)30-2093 2704 10099 Berlin Germany http://www.openca.org
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel