CVS update: /midgard/src/core/midgard/midgard/

"Jukka Zitting" <jukka.zittinggmail.com> 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. 
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-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org