On Wed, Mar 12, 2003 at 08:31:06AM +0100, Michael Bell wrote: > >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.
Ok, but we probably want to give ca.xml and ca.xml different names... > 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. Sounds good... As an alternative to ca.xml.template though (I like alternatives!), how about using xpath/xpointer (or whatever the standard is called, I always get these mixed up), eg: <template> <config name="country" xpath="/openca/software_config/country"/> [...] </template> Which would say: take the value of "country" from the input ca.xml file, search for the /openca/software_config/country element in the output data file, and replace it. This means you only have to replace certain elements in the XML file, not the entire file, and is more "XMLish". I suspect that there might be other benefits, but I can't think that far ahead just now. As for implementing it... I am not an experienced XML programmer... ;-) > >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: Just make this directory configurable. And watch out for potential security problems in /var/tmp, a malicious user could create a file called var/tmp/interface_name for instance, and stop openca from working. /var/lib/openca/ or /var/lib/openca/tmp/ might be better choices. > 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? Simple. Do you expect the adminstrator to want to make changes to the input files? If the answer is yes, then /etc/openca. If the answer is no, and nothing will change them except upgrading to a new version, then /usr/share/openca. -- Brian May <[EMAIL PROTECTED]> ------------------------------------------------------- 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
