Re: MidgardConfigFile

> Hi,

Hi,

>> There is also new midgard internal class MidgardConfig and we should remove
>> midgard structure usage after 1.8 is out.
>> Briefly,  we will be able to use objects for midgard connections ( for example )
>> with simple API :
>>
>> GObject *connection = g_object_new(MIDGARD_TYPE_CONNECTION, NULL);
>> GObject *config = g_object_new(MIDGARD_TYPE_CONFIG, NULL);
>>
>> midgard_connection_init(connection, config);
>
> Could you please elaborate. If we are changing the main entry points
> of midgard-core, then please, *please* document the API before
> implementing it.

Sorry, but this is a must IMO. Nothing to talk about.

> For example the above code sample gives no indication
> of which database is being connected,

Please elaborate :) You will create as many instances of MidgardConfig as many
databases you want to use. Additionally you could create as many MidgrdConnection
instances as many db you want to use.

We want to use one config file per db. No more no less.

> how errors should be handled,

Connection's one? That was only example which show you how to make OO core's
connection and configuration safe. Without any need to expose dbname , username
or password. Because you will simply *hide* it in MidgardConfig.

How do you report connection error in midgard-java without exceptions?

> etc. I'd also like to know if such an API would always require the
> configuration settings to be in a central configuration file, or could
> an application optionally construct the required configuration during
> runtime.

That's why I created MidgardConfig. Reading configuration from file is the first
method. Do you want to add another one? Please do.
Keep in mind that in every case you still hide critical data safe.

> Issue 1: Does it make sense to use GObjects here? What's the benefit?

How do you create midgard and midgard_config structures in midgard-java?
How you do this in exorcist?
How one will make it for midgard-python or midgard-ruby?

Probably 'config = new MidgardConfig' seems sensible , right?

> Issue 2: The current config.c is almost 700 (!) lines long. Wouldn't
> it make more sense to simply use GKeyFile for handling the
> configuration files?

Less sense. Please read my comments I added to this file more than 6 months ago.
That's not my fault that GObjects require so much code to be written.

Besides , you will remove 600 lines from midgard-apache2 module and you will write
500 lines less for any language bindings made in a future.

> You'd have essentially the same functionality
> (more actually, and much better tested) with at most 100 lines of code
> using GKeyFile.

Unfortunatelly we can not use GKeyFile.

Last questions from me:

How would you like to handle configuration file in midgard-apache module?
Create module related configuration struct?
Which duplicates poor midgard struct?
How do you want to use mgd_connect ( which MUST be changed ) after you create
configuration? Use another configuration struct?

Why do you complain about mess in MgdSchema code while you do not notice mess in
midgard sources beimg produced for the last 5~6 years?

Removing legacy code after 1.8 is out means removing almost *everything* which was
written before 1.7.
The sooner we start the better.

Piotras