Hi,

On 2/24/06, Piotras <pp@info...> wrote:
> > 0) Roadmap for the new configuration mechanism
> >    (beta in 1.8, stable in 1.9)
>
> http://www.midgard-project.org/development/roadmap/1-8/
> http://www.midgard-project.org/development/roadmap/1-9/

Excellent, agreed.

> > 1) Format of the configuration files
> >    (the GKeyFile format, perhaps using the real GKeyFile parser later on)
>
> 1. I already fixed boolean values. GLib supports also 0 and 1 as values.
> One should read sources to know this, so we support true or false now.
> 2. I am not sure about comments real syntax.
> 3. I am not sure if it's worth to write special code to parse values ( stripping spaces and duplicated equal signs )
> 4. Libgda config file location?

It's OK if we say that we use the GKeyFile syntax, but that there
might be some minor inconsistencies before the real GKeyFile parser is
used. The important thing is that people can use GLib to read and
modify the config files without worrying too much about the syntax
differences.

4. Libgda config files are named SYSCONFDIR/libgda/config and
$HOME/.libgda/config.

One more thing I'm wondering about the Midgard configuration file
format... Now each Midgard database is configured in a separate
configuration file with a single [Database] section. An alternative
would be to have just one configuration file with multiple sections
named by the configured databases. This would allow us for example to
have a nice global configuration section. Something like this:

----------
$ cat /etc/midgard/midgard.conf
[global]
Username=midgard
Password=xyz

[midgardstaging]
Name=midgardstaging
Blobdir=/custom/path/for/blobs/midgardstaging

[midgardlive]
Name=midgardlive
Blobdir=/custom/path/for/blobs/midgardlive
----------

We could also support the conf.d directory like this:

----------
$ cat /etc/midgard/conf.d/midgardtest.conf
[midgardtest]
Name=midgardtest
Blobdir=/custom/path/for/blobs/midgardtest
----------

> > 2) Location of the configuration files
> >    (SYSCONFDIR/midgard/conf.d/*.conf and $HOME/.midgard/conf.d/*.conf)
>
> Can we define it in configure script and statically in header file?
> I mean only $sysconfdir. I do not follow  XDG Base Directory logic here.

The configure script is a good place to do that.

> > 3) The API to read and construct configuration objects
> >     (See my MidgardConfig proposal a few messages ago)
> [...]
> MidgardConfig *midgard_config_new(void);
> gboolean midgard_config_read(MidgardConfig *config, const char *filename, GError **error);

That looks even better than the what I proposed. I'd actually like to
avoid the direct filename reference in the API and even the concept of
"reading" a file. It might be better to "load" a named configuration,
like this:

------------------------------------------------------------
/**
* Creates an empty Midgard configuration object. The application
* can load an existing configuration with midgard_config_load() or
* manually fill in the configuration parameters with g_object_set().
*
* \return empty Midgard configuration object
*/
MidgardConfig *midgard_config_new(void);

/**
* Loads the named configuration to the given Midgard configuration object.
* The named configuration is loaded using the standard Midgard configuration
* mechanism and the loaded configuration options are written to the
* given configuration object.
*
* Returns \c TRUE if the named configuration was loaded successfully.
* If the named configuration was not found or another error occurred,
* then the \c error placeholder (if not \c NULL) is filled with an error
* message and the return value is \c FALSE.
*
* \param[inout] config the configuration object
* \param[in]    name   name of the configuration to load
* \param[out]   error  placeholder for possible error messages, or \c NULL
* \return \c TRUE if the named configuration was loaded successfully,
*         \c FALSE otherwise
*/
gboolean midgard_config_load(
        MidgardConfig *config, const char *name, GError **error);
----------

This would make the API future-safe even for things like having
Midgard configuration stored in the Windows Active Directory!

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - info@yuka...
Software craftsmanship, JCR consulting, and Java development