Re: MidgardConfigFile

Jukka Zitting <[email protected]> wrote:

> Hi,

Hi,
 
> > > 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!

Yes , this is proposal for midgard connection API.
Not for configuration because midgard *never* had any configuration handler or API.
midgard struct is no configuration handler.
If you want to make it configuration and connection handler you need to change API anyway.
 
> > 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...

Currently dbname, dbuser and password are public , so it depends what property 
should be private or how should be accessible by internal method.
 
> > > 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!

I talk about hiding username and password.

GObject *connection = g_object_new(MIDGARD_TYPE_CONNECTION, NULL);
GObject *config = g_object_new(MIDGARD_TYPE_CONFIG, NULL);

midgard_connection_init(connection, config); /* returns TRUE or FALSE */

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

Jukka, I am far from proposing MIdgard connections handlers and API now.
What I wrote is the fact that we have ( at least ) *one* , uniform configuration handler.
And any language binding for that will be piece of cake when MidgardConfig is an GObject. 

What is better in Your opinion?

midgard struct ?
midgard_config struct  ?
directory_configuration struct ?

MidgardConfig object lets you set this GObject as mgd and dcfg member without any need 
to endless changes made to all those structures.

> > 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.
 
excuse me? 
gboolean midgard_config_read_file(MidgardConfig *object, const gchar *filename);

Should I elaborate about this?
I do not see any reason do add another configuratin init method. Add it, if you need.

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

Yes, it needs.

> To me the
> GObject overhead just seems like extra burden for the
> configuration/connection API.

"yes", let me think about ( for example ):
	mgd->blobdir
	mgd->config->blobdir
	dcfg->blobdir 

Keeping such data in one place , within GObject which can be extended easily
is indeed the "worst idea". 

> > Probably 'config = new MidgardConfig' seems sensible , right?
> 
> What's wrong with using a normal struct for that?

Which normal one? Point me to that good one exisitng in legacy code. Please do this.
 
> > > 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.

OK, I start to use 2.10 then. 
The point is that Midgard became popular last year becaue we started to take care 
about users. 
I think that Midgard is so "attractive" so every sys admin will just drop any stable 
productions environments in favour of the newest unstable software , just because
midgard developers really do not care about who is going to use it.

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

So the API will be very good now if you  shouldn't use more than 10 lines of code. 

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

Keep in mind:

	* must be backward compatible 
	* must be available in 1.8
	* available in 1.9 without many changes
	* available for midgard-php with php-cli
	* available for apache-php-midgard 
	* available for any command line
	* available for midgard-java	

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

Midgard2 API proposal? We should wait a bit. We just released 1.8alpha1.
 
> > 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.

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

Do you blame me for Midgard1.x architecture and all these hacks made from *the beginning* ?

Piotras