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

"Piotras" <pp-VVDi8QVAvoBWk0Htik3J/[email protected]> Fri, 17 Feb 2006 20:37:24 +0100 (CET)
Newsgroups gmane.comp.web.midgard.devel
Message-ID <[email protected]>
> Hi,

Hi,


> Questions about the current config interface:
>
> 1) Will the new configuration mechanism be the preferred one already
> in 1.8 or only in 1.9 as mentioned in the roadmap?

We need to use new config files at least for midgard-schema.
After 1.8 is out this mechanism will be the only one ( preffered ).

> 2) Will midgard_config_read_file() be the correct and only way to get
> midgard configuration?
>
> 3) Why do I need to pass the full file path to
> midgard_config_read_file() when there is a standard directory for the
> config files? Is the conf.d directory just a common convention, or is
> it absolutely required that all config files be located there?

absolutely required, conf.d path follows the prefix

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

> 4) Could we please use the GKeyFile functions to parse the file?

I would love to.

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


> 5) Currently it seems that the MidgardConfig object is only used by
> midgard-apache2 to get the traditional configuration options to be
> passed to midgard-core.

and midgard-schema
We can add Apache1 support but we can not define root file location.

> Will this change, i.e. will there be a funtion
> like midgard_connect(MidgardConfig *config)?

I think you answered with your proposal :)

> 6) Are there any ideas on how the configuration mechanism will change
> when we switch to libgda? There is a full data source configuration
> mechanism in libgda so we could in principle just use a single data
> source name to get the database connection.

But we need midgard releated options , very important for me is for example
loglevel which become be usefull.

> My idea of a perfect configuration/connection API for Midgard would
> look something like this:
>
>     GError *error = NULL;
>     MidgardConnection *connection =
> midgard_connect("my-midgard-database", &error);

I hoped that I will propose it ;)
Almost no more no less and +1000 from me.

I am not sure about midgard_config object which should be passed as parameter.
But it depends on internal implementation.
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 ).

Another question is , if we need change midgard connection data while changing
its configuration? Rather silly question as there should be another instance, but I
prefer to ask just in case.

And another one, how to handle MidgardPerson while config is hidden in connection?

I would like to vote for midgard_config passed as connection argument and gerror
as another one.

Piotras