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

"Jukka Zitting" <[email protected]> wrote:

> Hi,

Hi,
 
> > ( 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. )
> 
> I'm OK with keeping also the MidgardConfig as a GObject.

I would like to propose a simple convention.
What's GObject in core is designed for language binding, while what isn't GObject 
should be used only in core.
 
> > Right. But now I think that we could rename midgard_connection to midgard.
> > Then midgard is connected or not. ... and less typing ;)
> 
> I think it's better to keep the "connection" in the name. It was an
> error originally to name the Midgard struct as "midgard". It kind of
> works when you have just one midgard connection, and you can keep that
> as a part of the semi-global "midgard" struct, but the naming fails
> when you want to have more than one connection. Think of "this midgard
> / that midgard" vs. "this MidgardConnection / that MidgardConnection",
> a more descriptive name makes things easier to grasp.

OK.
 
> >
> > 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.
> 
> No, the GLib logging methods are per application, not per connection
> or any single application data structure. Instead the GLib logging
> framework allows you to distinguish log messages by log domain (the
> library that logged the message) and log level. In addition you can
> define all kinds of log handlers for different log domains and levels.

Well, if those three hosts use the same connection ( if "pooled" ) then 
every request is an application.
 
> My point is that we don't really need per-connection logging, and thus
> any per-connection log configuration or API is wrong. The GLib logging
> framework is good enough for us and the only information a client
> needs to use the framework is the log domain used by midgard-core.
> This brings us to midgard_get_log_domain()...

OK, I think I still do not understand. What we need is not even per application 
or per connection. We need something which is changeable during runtime or request.

>     a) use g_log_set_default_handler() to handle log messages from
> *all* log domains, or

Yeah, but this is GLib 2.6 :/

>     b) use g_log_set_handler() to handle the log messages from just that library
> 
> To use option b, the application needs to know the log domain used by
> the library. The midgard-core log domain is currently "midgard-core",
> but to avoid duplication and to make it easier to change the log
> domain, its better if the application uses a separate function like
> midgard_get_log_domain() to get the log domain used by midgard-core. A
> somewhat common idiom is to also provide the log domain as a
> MIDGARD_LOG_DOMAIN macro that looks more like a constant and is more
> consistent with G_LOG_DOMAIN.

OK, help me with real issue now.
While you use repligard in HEAD you use "repligard" G_LOG_DOMAIN , while core 
has "midgard-core" and "midgard-lib" defined.  
What should I do to make core "silent"  instead of logging *everything* ?
Without g_log_set_default_handler().


BTW:
Coming back to lang and sitegroup GValues issue.
What do you think about such changes:
extern void midgard_connection_sitegroup_set(MidgardConnection *mgd, GValue *value);
to
extern void midgard_connection_sitegroup_set(MidgardConnection *mgd, MidgardSitegroup *sitegroup);
and similiar:
extern gboolean midgard_connection_set_lang(MidgardConnection *connection, MidgardLanguage *language);

Piotras