Jyri Virkki wrote: > > You could do it in the future. Or you could definte the mechanism > (location and inclusion rules) now and only later make use of it. > Earlier is nicer than later, but your choice. >
I've added details about conf.d and a couple of config files that we can include in the integration. There's also one line describing how they are used and it's very straightforward. Users can use the conf.d directory for their own config files which they can then include in the main config file, we just provide some files to get them started on common tasks. It's not zero configuration though as the still have to enable the modules. This will be mentioned in the umbrella man page. > Uncommitted is quite stable for the long term. Are these access log > files using common log format (or similar standard format) in which > case Uncommitted (or even Stable) might be correct? Or are these > free-form strings for human consumption? If the latter, is there a > guarantee they will remain constant so if I write a log file parser > it'll continue to work across releases? > > Log files meant for human consumption only (not for scripts to parse) > are typically classified as "Not An Interface" which means they're > public, but not meant as a programmatic interface. > I've changed it to "not an interface", I have examples on the tests I'm running that would break log file parsers. The log files for now are strictly for human consumption. I now just have some validation to do on the module support we are including. Amanda -- Amanda Waite ISV-Engineering OSS, Sun Microsystems Tel: +44 (0)1252 420693 Mobile: +44 (0)7802 175732 AIM: pollyemic
