"Jukka Zitting" <jukka.zitting@gmai...> wrote:

> Hi,

Hi,

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

Now we have many duplicated data as members for different structures: mgd, rcfg, dcfg.
If you close connection ( only connection ) you need to set config as member of dcfg to
avoid reopening. You want to reuse it with another  request.
Simply , those three structures could have the same member MidgardConfig *config.
( Config may be struct or GObject. I preffer GObject as sooner than later we need to write
datagard like tool with PHP, so I can consider this part of binding as done. )

If connection is closed ( RSHUTDOWN ) and opened ( RINIT )  during the request , I can forget
about rcfg structure as mgd is enough in this case.

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

Yep. :D Couldn't be better!
This is attachments' handling topic , but +10 from me.

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

Right. But now I think that we could rename midgard_connection to midgard.
Then midgard is connected or not. ... and less typing ;)

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

So probably I misunderstood something.
What we need is to start g_debug logging for vhost A during request Y,
keep g_warning logging for vhost B in all requests and use
g_info ( is it already ?) for one function during request for vhost C.


> 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;
>     }

Now , I completely do not follow :)

Piotras


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@midg...
For additional commands, e-mail: dev-help@midg...