>> > Couldn't we use something like g_key_file_load_from_data_dirs() to
>> > automatically find the configuration files from the default system
>> > locations?
>>
>> I haven't available docs here. What's minimum GLib version?
>
> GLib 2.6, but this can be relaxed as described below. The
> freedesktop.org standard basedir locations
> (http://www.freedesktop.org/Standards/basedir-spec) used by
> g_key_file_load_from_data_dirs() don't seem to match our needs very
> 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.

>> > Requiring glib 2.6 or even using a local copy of the glib 2.6 GKeyFile
>> > sources would be a small price for this.
>>
>> Can we do this?
>
> Yes. GLib is LGPL and the gkeyfile.c is mostly quite modular. We can
> use a configure option to activate a local copy of the GKeyFile
> implementation if GLib 2.6 is not available. If you want I can write
> the configure magic for this.

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 think we have major issues resolved in 1.8 and few new important features,
so delaying 1.8 is the last thing I personally want.

>> But we need midgard releated options , very important for me is for example
>> loglevel which become be usefull.
>
> True. I was thinking that we could for example deprecate the old
> database configuration parameters and prefer the libgda data source
> 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?

>> Briefly I would like to initialize configuration and log handler before I will
>> initialize connection.
>> And for example I would like to change runtime loglevel so midgard_config object
>> could be helpfull here. But on the other hand I am not quite sure as we need some
>> persistant ( application's configuration , let's say vhost ) and runtime's one (
>> let's
>> say request ).
>
> I'd prefer if we didn't have any specific log handlers or logging
> configuration in midgard-core. Just use the normal
> g_{debug,message,warning} macros for logging within midgard-core (the
> core should never have critical or fatal errors) and let the
> application define a log handler for the "midgard-core" domain if it
> wants to.

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.

> For example midgard-apache may want to define a log handler
> that writes to the Apache error log while a Java application might use
> log4j for logging. It's inconsistent if midgard-core would write a
> separate log file.

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.

>> And another one, how to handle MidgardPerson while config is hidden in connection?
>
> What do you mean? Which MidgardPerson?

You should define SG person in configuration file. The same like you do in
repligard.conf. So to call mgd_auth you should be able to get username
and password somehow.

Another options are testunit or tablecreate etc . I can not hide them in connection
handler because I work with configuration which "holds" connection. On the contrary
in practice but I think you get an idea.

>> I would like to vote for midgard_config passed as connection argument and gerror
>> as another one.
>
> How about if we allowed both a name string and a full config object as
> alternative connection options. The preferred interface would be to
> use the higher level function with a database configuration name, but
> a config object could also be used to allow more flexibility for
> applications that need it:

Let me think about API for a while.
As I wrote we need "two" configurations.
Loglevel is a best example ;) you define warn in vhost config while during the
request time you define debug. For three lines of code. It's very usefull feature.

> Note also that IMHO the MidgardConfig API seems a bit unnecessary. We
> could just replace it with GKeyFile and get the exact same
> functionality.

Similiar. But I may be wrong.
MidgardConfig makes language bindings much easier to write than GKeyFile.
At least you do not have to write additional binding if you have GObject to language
object "wrapper". Boolean properties will keep boolean values always the same way
and it doesn't matter how you get and define them from, and in config file.

I think we will have to share some data between configuration object and connection
one. Sometimes replace them. GKeyFile will be difficult in such case.

Piotras


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@midg...
For additional commands, e-mail: dev-help@midg...