Re: MidgardConfigFile

Hi,

On 1/5/06, Piotras <[email protected]> wrote:
> You define database name in configuration file , so:
>
> 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? 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.

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.

> We should probably run doxygen with HEAD header files. I write as much "doxygen
> ready" docs as possible ATM.

I'm very thankful for that! The problem however is that you normally
write the docs at the same time when you implement stuff so I can't
give feedback until it's too late. Example:

> Your  API proposal is very good , but not practical.
>
> For example in midgard-php I should abuse g_type_from_name to use this API,
> and there is no proposal for midgard like struct handling.
>
> For example:
>
> MidgardObject *midgard_object_find(GType type, guint id);
>
> How should I define mgd struct and thus connection handler for this?
> This function returns object so I can not set this as property value or
> method parameter.

This is exactly the feedback that is useful. You are right, there is a
design flaw in this function that should be fixed. In fact the entire
function should nowadays be removed in favor of the QB.

Now, had I announced that API after already implementing it, we'd have
a problem and I'd have to rewrite lots of stuff. Because I didn't, we
can discuss the proposal on a high level without concern for existing
code.

Of course the mRFC 0016 draft is already badly outdated so I should
probably just let it expire.

> 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, cleaner schema loading, better
definition of MultiLang semantics, reflection features, streamlined
schema file format, etc. I'm not making noise for nothing, these are
all real issues that make my life a lot harder with midgard-java.

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.

PS. I've got a major JCR contract starting late March and lasting at
least till the end of this year. So although I certainly won't be
abandoning Midgard, I'll have less time and commercial interests in
working with it. 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.

BR,

Jukka Zitting

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