Hi,

On 3/3/06, Piotras <pp@info...> wrote:
> Those must be written anyway. You need to initialize struct and free it anyway.
> But this is still proposal , so I do not say +1 or -1.

OK, you may be right. There could be cases where having the connection
as a GObject would be nice. We could for example add signals for
different database actions or clients could attach custom data to the
connection GObject. So forget my ramblings, +1 to using GObjects.

> I am not sure if I follow you here. If you want to open and close connection
> without a pool then we can forget about duplicating structures for rcfg.

What do you mean by "duplicating structures for rcfg"?

> > What do you need the type for? To differentiate sitegroup ids from
> > sitegroup guids (or names)? Wouldn't it be better if we just selected
> > one of these options as the standard way to identify a sitegroup and
> > designed the API accordingly.
>
> That would be perfect , but I doubt we can change so many things before 1.8
> is out. But anyway we can hide some "overhead" in this API now.

It's a new API anyway, so I wouldn't worry about too many changes.

> >     GIOChannel *midgard_connection_get_attachment_data(
> >             MidgardConnection *connection, MidgardObject *attachment_object);
> >
> > This way the client application doesn't need to know where the blobs
> > are actually being stored.
>
> This is what I really would like to avoid. It's not logically IMO.
> It's not related to connection and forces us to make MidgardConnection as a
> "wrapper" for configuration itself. And in a long run it will be something with long
> listed API like it's now with all mgd_xxx in core.

Then how about:

    GIOChannel *midgard_object_get_data(MidgardObject *attachment_object);

My point is that we should not expose the blobdir to clients. An API
like the above hides the blobdir configuration and allows us to for
example start storing attachments in the database, on the web, or
wherever we want. Call it future-proofing the API. :-)

> If you close connection at RSHUTDOWN you need to reuse configuration again
> in RINIT, so you need to handle it somehow. Or reopen configuration.

Exactly. I'd reuse the configuration, see below.

> Midgard
>     |
>     ---MidgardConnection
>         |
>         ---MidgardConfig

I'd rather have MidgardConnection and MidgardConfig object as
independent entities with no HASA relationships. A MidgardConfig
instance can be used to instantiate a MidgardConnection, but it is not
contained in the MidgardConnection.

The MidgardConnection instance should copy any configuration settings
it needs to remember. This allows us to reuse the configuration and
keeps the object ownership issues clean and simple.

> > The GLib logging framework only allows you to
> > specify log handlers per logging domain, not per Midgard connection.
> > Even the current default log handler hack in Midgard fails miserably
> > if you want to simultaneously connect to two databases with different
> > log configurations.
>
> The same connection for two databases?

No. Consider a case where you have two Migard databases, a good
example would be "staging" and "live". You've configured the "staging"
connection with logging to "staging.log" and the "live" connection
with logging to "live.log". If you now want to create an application
that wants to use these databases simultaneously (think of Exorcist),
the log messages for *both* databases would end up in either in
"staging.log" or in "live.log". The g_debug(), g_warning(), etc.
logging functions do not support per-connection logging. Thus it
doesn't make sense to have per-connection log settings.

It seems that something like the following is a more widely used
convention than a midgard_set_log_handler() function:

    #define MIDGARD_LOG_DOMAIN midgard_get_log_domain()
    extern const char *midgard_get_log_domain(void);

And:

    const char *midgard_get_log_domain(void) {
            return G_LOG_DOMAIN;
    }

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - info@yuka...
Software craftsmanship, JCR consulting, and Java development