Re: MidgardConfigFile

Hi,

On 1/4/06, Piotras <[email protected]> wrote:
> > 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.

Nothing to talk about? You're proposing a major change to the
configuration/connection API!

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

I figured as much, but how do you specify which database configuration
to use? Your code sample contains no connection/database/configuration
file name...

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

There definitely should be some way for an application to detect
connection errors, you can't just *hide* them!

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

Exceptions are the standard error notification mechanism in Java, so I
see no reason to not use them there. In a C API you'd normally use
either a return value, an errno variable, or a GError parameter.
Please specify what mechanism you were planning to use.

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

I'd be glad to do that, but I cannot do that unless you specify the
default configuration API in with enough detail.

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

GObject is generally only useful for language bindings when you're
handling generic objects that could have any number of different
properties, signals, etc. I don't think that a Midgard connection or
configuration object would much need things like this. To me the
GObject overhead just seems like extra burden for the
configuration/connection API.

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

What's wrong with using a normal struct for that?

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

You mean the fact that GKeyFile is only available since glib 2.6?
What's stopping us from taking the GKeyFile code from a newer glib and
including it in midgard-core for use with older glib versions? It's a
bit of a kludge solution, but still way better than implementing the
same functionality again.

Actually I'd just make glib 2.6 a dependency of midgard 1.8. It was
released over a year ago and glib is already running at version 2.9.

> That's not my fault that GObjects require so much code to be written.

That's exactly my point about the unnecessary overhead. It's fine when
the extra functionality gained by using GObjects is needed, but I see
no reason for overusing GObjects.

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

I really wouldn't expect to use more than 10-20 lines with the
configuration/connection API in a language binding in any case. The
API is seriously broken if it requires more.

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

Are you asking me to propose a configuration/connection API for the
core? I'd actually be happy to do that, but I'm somewhat discouraged
by what happened to the MgdSchema API proposals I made last spring.

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

I'm eagerly waiting for the moment we'll be dumping the legacy code so
I see no reason to complain about the mess there. I'm much more
worried about the fact that the core Midgard 2.0 functionality is
*already* showing signs of degeneration.

The fact that we're postponing the core cleanup to post-1.8 feels like
a worse decision the longer the 1.8 cycle seems to take. The longer we
support the current quirks the more backwards compatibility issues
we'll have once we get to start the cleanup.

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - [email protected]
Software craftmanship, JCR consulting, and Java development