Re: MidgardConfig comments (Was: [midgard-dev] Automake and directories)

Hi,

On 2/18/06, Piotras <[email protected]> wrote:
> >    a) Location of the system configuration files
>
> We can add them whenever we want and current GHashTable lookup or
> GKeyFile propper usage doesn't matter I think. Does it?

That doesn't matter, but we definitely should select the correct
config file location from the beginning. Will
PREFIX/etc/midgard/conf.d be that one place? Will the configuration
files within that directory have a suffix (.ini/.conf/...) or not?
These need to be decided and documented.

> > b) Support for per user configuration files
>
> Per user in db config file?

I mean do we plan to support something like $HOME/.midgard/ as a local
place for midgard configuration files?

> > c) Comment syntax
>
> Don't all comments begin with '#' ?

The current config file parser in src/config.c ignores all lines that
do not contain "=". A line like "#foo=bar" would be parsed as "#foo"
=> "bar". Such an option is of course ignored by the config handler,
but this sure s confusing when trying to decipher the file format from
the sources. Note that the only documentation of the file format is
the term "ini-like" on the wiki and the example file
conf.d/midgard.conf.example.

> > d) Whether spaces around "=" in "name=value" are ignored
>
> This is issue which can be ignored right now I think.
> In 1.8 you should "edit" config file from dg level or manually ,
> if you know what you are doing.


> > e) Format of boolean values
>
> I do not understand.

Should boolean values be "yes/no" or "true/false". The current
src/config.c uses "yes/no", while GKeyFile uses "true/false".

> But benefit of MidgardConfig is that you do not have to worry about what config file
> looks like and how is parsed. Right?

But I *do* need to worry about it if I'm to use that information
anywhere else than the standard Midgard tools. For example I could
want to write a backup script that locates and backs up all configured
Midgard database and the related blob directories. The only way to do
this correctly is to have clear and detailed documentation of the
configuration file format and the configuration options. Another good
example would be a GUI tool for configuring Midgard databases.

> You are always able to change loglevel and default log handler. So I do not see
> any problem here.

This wouldn't be too bad if midgard-core only registered a log handler
for the "midgard-core" domain, I'd just have an extra log file or
stuff being printed on stderr with no way to send that stuff to for
example syslog... What's really bad about the current situation is
that Midgard overrides the *default* log handler, basically hijacking
all application log messages.

> No. Personally I am very tired of midgard-php being actively used while
> being something between php and apache extension.
> Once we removed that dependency in 1.7 we should never come back there.

I don't see a problem here. Midgard-php could very well use the same
midgard_set_log_handler() mechanism to route core log messages in
whatever way it wants.

> We shouldn't set this when request starts. You must be able to set
> handler anytime you need. Even in the middle of the request.

GLib allows you to have multiple different log handlers.
Midgard-apache should set a handler to route messages to the Apache
error log, but midgard-php is free to define other handlers for the
same messages whenever it wants to. The current approach of changing
the global default log hander is much less flexible.

> >     LogLevel warn
> >     ErrorLog /var/log/httpd/main.error.log
> >     <VirtualHost foo.com>
> >         LogLevel debug
> >         ErrorLog /var/log/httpd/foo.error.log
>
> OK, how would you like to manage loglevel , logfile and log handler then?
> We need to be able to set it from midcom level while being completly
> Apache unaware. The other thing is php-cli.

As I mentioned above, you can have custom logging also in midgard-php
if you want. I think the default should however to write log messages
to the (correct) Apache error log unless otherwise specified.

> Which is logic IMO , you define midgard log level , not Apache's one.
> In practice ( look back at midgard user and dev list ( ~ 3 years ) )
> we usually need to set midgard log level and handler from *any* level.
> Apache loglevel is tha last thing we usually need to touch.

That sounds a bit backwards to me. The ErrorLog directive is the most
standard and well-known log configuration mechanism for Apache
environments. Of course you would be able to customize the logging if
you really want to, but IMHO we should fully support the ErrorLog
directive as the default mechanism.

> I look at Torben now.
>
> 1.
>         $midgard = new midgard();
>         $midgard->read_config("filename");
>         $midgard->connect();
>
> is much preffered way than mgd_connect.

Agreed. Whatever the PHP API will be, the default configuration
mechanism should just take a single string like in the example above.

> 2.
>         Core uses GKeyFile
>         midgard-php arrays
>         midgard-java objects
>
> I do not like it.
> Especially when we are going to use PHP5 soon with improved OO mechnisms.

The default and preferred mechanism for all bindings should be to use
just a single string that identifies the configuration file to use. It
really couldn't be simpler.

But *if* the application needs to do dynamic configuration, it should
be possible to use the lower level API that accepts the name-value
configuration options in whatever format we choose. In Midgard-Java
I'd most likely handle such dynamic configuration options using system
properties. In PHP the standard way would be to use a hash array (see
for example DB::connect() in PEAR).

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - [email protected]
Software craftsmanship, JCR consulting, and Java development