Re: MidgardConfig comments (Was: [midgard-dev] Automake and directories)

Hi,

On 2/18/06, Piotras <[email protected]> wrote:
> > I'd rather *not* have the new config stuff in 1.8 if we end up having
> > to change it for 1.9. It's a totally unnecessary backwards
> > compatibility issue.
>
> Something else except database directives?

Details like:

   a) Location of the system configuration files
   b) Support for per user configuration files
   c) Comment syntax
   d) Whether spaces around "=" in "name=value" are ignored
   e) Format of boolean values

None of these is too hard by itself, but they do add up to a real
backwards compatibility issue. If we endorse the current MidgardConfig
in 1.8, then IMO we should not change it later on.

> > My point is that midgard-core should not try to decide which levels
> > are being logged. It should just log messages using the logging macros
> > and let the application decide the log level.
>
> I am not sure if I understand you here. What I am talking about is *using*
> GLib log macros with mgd_log_debug_default support which allows you
> print only those log levels which are set in configuration.

My point is that midgard-core should *not* set it's own log handler.
We can provide a function like the following, but it should be the
client application that provides the log handler.

------------------------------------------------------------

/**
 * Sets the log handler for the messages logged by the Midgard core.
 */
guint midgard_set_log_handler(
        GLogLevelFlags levels, GLogFunc handler, gpointer data) {
        return g_log_set_handler(G_LOG_DOMAIN, levels, handler, data);
}

/**
 * Removes the identified log handler from the Midgard core.
 */
void midgard_remove_log_handler(guint handler_id) {
        g_log_remove_handler(G_LOG_DOMAIN, handler_id);
}

------------------------------------------------------------

With such an API midgard-apache2 could easily redirect all
midgard-core log messages to the correct Apache log handler:

------------------------------------------------------------

void log_handler(const gchar *domain, GLogLevelFlags level,
                 const gchar *message, gpointer data) {
        request_rec *r = (request_rec *) data;
        int aplog_level = APLOG_INFO;
        if (level & G_LOG_LEVEL_ERROR) {
            aplog_level = APLOG_CRIT;
        } else if (level & G_LOG_LEVEL_CRITICAL) {
            aplog_level = APLOG_ERR;
        } else if (level & G_LOG_LEVEL_WARNING) {
            aplog_level = APLOG_WARNING;
        } else if (level & G_LOG_LEVEL_MESSAGE) {
            aplog_level = APLOG_NOTICE;
        } else if (level & G_LOG_LEVEL_INFO) {
            aplog_level = APLOG_INFO;
        } else if (level & G_LOG_LEVEL_DEBUG) {
            aplog_level = APLOG_DEBUG;
        }
        ap_log_rerror("midgard", 0, aplog_level, 0, r, "%s", message);
}

------------------------------------------------------------

when request starts:
        request_rec *r = ...;
        guint log_handler_id = midgard_set_log_handler(
                G_LOG_LEVEL_MASK, log_handler, r);

when request ends:
        midgard_remove_log_handler(log_handler_id);

> > What if I have per virtual host ErrorLog directives in my Apache
> > config? I'd much prefer having the Midgard warnings printed in those
> > logs instead of the default stderr log.
>
> I just talk about this. Apache ErrorLog is stderr in your case.
> So do not define midgard logfile  and all messages will be logged to file
> defined for Apache's ErrorLog directive. It works.

Nope. Consider the following configuration:

    LogLevel warn
    ErrorLog /var/log/httpd/main.error.log
    <VirtualHost foo.com>
        LogLevel debug
        ErrorLog /var/log/httpd/foo.error.log
    </VirtualHost>
    <VirtualHost bar.com>
        LogLevel info
        ErrorLog /var/log/httpd/bar.error.log
    </VirtualHost>

In this setup the midgard-core log messages would end up in
main.error.log regardless of the site being processed. What's also
troublesome is that if the midgard configuration uses the "debug" log
level then the main.error.log will end up containing midgard debug
messages even if the Apache LogLevel setting is higher.

> What I have to do to make MidgardConfig available on PHP level is to define
> Zend class and its methods ( if exists ). Property setter and getter may be used the
> same which is used for MgdObject(s).

There should be no need to handle the config objects in a normal
Apache/PHP enviroment. The midgard-apache module just uses
MidgardConfigFile and passes the given parameter to
midgard_connection_open(const char *, GError **). No need to
instantiate or manipulate any config objects.

The only reason I can think of for using the config objects in PHP is
using PHP-CLI and manually setting up the midgard connection with
mgd_connect(). I think a normal PHP array would be good enough to pass
any configuration options to mgd_connect().

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - [email protected]
Software craftmanship, JCR consulting, and Java development