Re: MidgardConfigFile

Jukka Zitting <[email protected]> wrote:

> Hi,

Hi,
 
> >
> > GObject *config = g_object_new(MIDGARD_TYPE_CONFIG, NULL);
> > midgard_config_read_file(config, "myconfig");
> > midgard_connection_init(connection, config);
> 
> So you mean if I have a an application that is given the required
> configuration parameters (database name, host, blobdir, etc.) instead
> of an existing configuration file, then the application should first
> write those parameters to a temporary config file, read that file with
> midgard_config_read_file(), and finally delete the file? 

It depends. 
If you want to work with some database and have no configuration file , 
*and* database should be local database , then it means that this database 
doesn't exists at all, and you must use tool like datagard to create database 
and particular configuration file. Then you just get configuration from this file.

If you need persistant remote database configuration , then you should also 
use tool like datagard to create configuration file and then use this configuration.

For ad-hoc remote database or *pure* desktop application both solutions ( mine and yours
are bad ).  In such case , configuration should be handled quite different way and probably 
explicit object's setters should be added.

>I think
> that's a major inconvenience that could easily be solved by allowing
> explicit configuration settings. It would also make it a lot easier to
> implement backwards compatibility for the current MidgardDatabase,
> etc. configuration directives.

g_object_get(G_OBJECT(dcfg->config), "dbname", &dbname, NULL);
/* Pay attention that we do not implement our API in this case */

vs:

dcfg->dbname
/* duplicated structures on few levels */

or

g_key_file_has_key ()
/* you must remember all configuration file directives with keys and groups */
 
/* you must duplicate similiar code many times: */

        self->private->dbcreate = FALSE;
        tmpstr = g_ascii_strdown(dbcreate, -1);
        if(g_str_equal(tmpstr, "yes"))
                self->private->dbcreate = TRUE;
        g_free(tmpstr);

/* You can not use g_key_file_get_boolean () in such case 
* Because we create integers or booleans configuration's values from string. */

or

midgard_config_get_blobdir(config);
/* this requires two API functions per every configuration's key */

> This is my main concern about the API you proposed. The other stuff
> (GObject overhead, etc.) is just rambling compared to this so I'll
> just drop it.

Before you want to do this, please take a look at midgard-apache module , midgard-php 
module initialized from cli or as apache module and midgard cli tools.

Especially take a look at midgard apache's 2 module and MidgardConfigFile directive.
When we move it to GObject , we can use there code like this:

GObject *config = g_object_new(MIDGARD_TYPE_CONFIG, NULL);
if(midgard_config_read_file(config, filename)) 
	dcfg->config = config;

3 ( three!!!) lines of code to initialize directory config for midgard vhost. 

Yes, we can use there simple C structure, but:

1. Do we need to have the same members in three different structures on few levels?
2. Do you want to maintain all these structures and code related to them?
3. Isn't GObject's get property  suitable to forget about internals structures and any kind of API?

> > I have almost 0 feedback from you about midgard-java bindings problem.
> 
> Then I'm doing something really wrong. :-) I think I've been bugging
> you about this for the best part of last year. Things like a
> documented API for MgdSchema,

Yes, you are right , but the point of MgdSchema is that you should only load it and follow GObjects.

> cleaner schema loading, 

This is a topic for a long thread I think.

> better
> definition of MultiLang semantics, reflection features, 

This is something we just planned , and there were *no time* to make it earlier.

> streamlined
> schema file format, etc.

We *both* decided that we keep MgdSchema code and issues untouched and we will 
focus on this after 1.8 is out. 

>  I'm not making noise for nothing, these are
> all real issues that make my life a lot harder with midgard-java.

I was rather asking about problems with update, create , get_by_xxx methods.

> I've even been very willing to discuss, plan, specify and implement
> these features, but your usual response has been "not yet" or more
> recently "after 1.8". After ten months of waiting for "not yet", I'm
> getting a bit frustrated.

Because we still do not have 1.8 ?
Just try to not forget that we still *use* MIdgard 1.x architecture.

> So if you want my active feedback and participation
> in specifying and implementing the Midgard 2 internals, I suggest we
> start working on it already before the scheduled March 30th release
> date of 1.9 alpha.

First thing I will do for 1.9alpha will be midgard-php code cleanup.
Next,  I will remove legacy core code. 
Next , I will focus on connection , configuration or runtime settings handler.

We just talk about the thing which should be ready before we start writing more 
code for 1.9, 2.0.

Piotras