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

Hi,

On 2/18/06, Piotras <[email protected]> wrote:
> > well, using a configuration search path like
> > $HOME/.midgard:$prefix/etc/midgard/conf.d would be nice.
>
> Yeah, I just reminded myself tigert's blog about making application
> faster and lighter.

I hardly think that an extra stat() or fopen() per connection is a
performance concern. A *single* SELECT takes a lot more time.

> Your help is always appreciated , but I wonder if we desperately need this for
> 1.8. If configuration file syntax keeps GLib logic I would like to keep it asis
> and focus on making 1.8 out. After that we will switch to GLib >= 2.6.

I'd rather *not* have the new config stuff in 1.8 if we end up having
to change it for 1.9. It's a totally unnecessary backwards
compatibility issue.

> > configuration instead. Then we would just have a single DataSource
> > configuration option in the Midgard configuration file that refers to
> > the more detailed libgda configuration.
>
> A new configuration file?

Yes, but one with existing tool support. See for example:
http://www.gnome-db.org/images/screenshots/manager_component.png

> yes, we follow GLib log levels, nothing new. I tuned midgard log handler
> a bit so now we are able to configure which level should be used.

My point is that midgard-core should not try to decide which levels
are being logged. It should just log messages using the logging macros
and let the application decide the log level. Wouldn't it make sense
to make Midgard log messages follow for example the Apache LogLevel
directive?

> no no. it's an option.
> You define loglevel to message and midgard-apache and midgard-php should
> follow this level.
> If you keep logfile empty, then stderr is used. Apache error log in such case.
> If log4j is used as stderr then we are fine.

What if I have per virtual host ErrorLog directives in my Apache
config? I'd much prefer having the Midgard warnings printed in those
logs instead of the default stderr log.

> MidgardConfig makes language bindings much easier to write than GKeyFile.

That's not true. The config object is just a collection of name-value
pairs. Even a GHashTable or a plain old struct would be good for that.

The benefit of GKeyFile over all other approaches is that it uses a
*standard* configuration file format that can be easily edited
manually *and* programmatically. There are even existing GUI and
command line tools for reading and manipulating GKeyFile configuration
files.

BR,

Jukka Zitting

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