Re: Fwd: [midgard-cvs] CVS update: /midgard/src/core/midgard/midgard/

"Jukka Zitting" <[email protected]> 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