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

"Jukka Zitting" <[email protected]> wrote:

> > 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.

I think this should be a matter of convention.
Both should work IMO.
'filename' and 'filename.conf' passed as argument 

Personally I do not care about file extension so much. 
 
> > > 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?

Oh, of course.
I was thinking that you suggest another directive which point to user config.

 
> > > 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. 

Yes, you are right. Current "parser" is poor replacement.

>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.

Sorry. I have no idea how to describe better database directive.
 
> > > d) Whether spaces around "=" in "name=value" are ignored

yeah, right

> > > 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".

That is absolutely my fault. I was sure that yes/no true/false are supported.
 
> > 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.

Yes, we need this.
I fully agree with you. What I would like to suggest is to change ini file syntax
that way so we could use current parser and make GKeyFile support after 1.8.

> > 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.

OK, I wanted to log to one file to avoid plenty of log files mess.
We can do it , but it's painfull when you need to help someone.
 
> > 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.

ok , just tell me how can I know using three log files that this query is executed
before this php function and after this apache call?
 
> 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.

Yes, but for Apache only , not for PHP.
 
> 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.

Yes, that's why all new configs are made this way.
 
> 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).

No , I do not want to look at this. I am interested in what will be good for PHP5
and can be implemented for PHP4.

Piotras