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

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

> Hi,

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

Yes, I forgot to add ';)'.
 
> > 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.

Something else except database directives?
 
> > > 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

I know that :) I was wondering how and  when to support it. Files' location etc.
 
> > 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. 

I am not sure if I understand you here. What I am talking about is *using*
GLib log macros with mgd_log_debug_default support which allows you 
print only those log levels which are set in configuration.

> Wouldn't it make sense
> to make Midgard log messages follow for example the Apache LogLevel
> directive?

No. It doesn't help at all. In 99% you need to debug from PHP level. 
Well... anyway , even if we could follow Apache LogLevel you always must be 
able to "redefine" and set different log level from application. PHP script in this case.
 
> 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.

I just talk about this. Apache ErrorLog is stderr in your case. 
So do not define midgard logfile  and all messages will be logged to file
defined for Apache's ErrorLog directive. It works.
 
> > 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.

What I have to do to make MidgardConfig available on PHP level is to define
Zend class and its methods ( if exists ). Property setter and getter may be used the 
same which is used for MgdObject(s). 
GKeyFile is much work in this case and much work for keeping non object 
to object logic.
Besides when I use MidgardConfig object I am sure that midgard-java and midgard-php 
will have the same functionality.


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

Yes, I was thinking about this when I was looking at newt ( whiptail ) API usage.

Piotras