MidgardConnection (Was: CVS update: /midgard/src/core/midgard/midgard/)

Hi,

Changing the subject to a bit more descriptive one. 

On 3/6/06, Piotras <ppinfoglob.com> wrote:
> 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.

I wouldn't be that strict. Use what best suits the
requirements. Using
GObjects is no magic dust to make language bindings easy,
GObjects
just provide a standard set of features (properties,
signals, data
attachments, inheritance, introspection, etc.) that is well
supported
in a variety of environments. Using GObjects for stuff that
doesn't
need those features (for example MidgardConnection doesn't
really need
generic properties or introspection, but signals and data
attachments
might be nice) is just extra work.

> > a) use g_log_set_default_handler() to handle log
messages from
> > *all* log domains, or
>
> Yeah, but this is GLib 2.6 :/

You're already using it in src/config.c. In any case we
shouldn't be
using either of the g_log_set functions in midgard-core. If
an
application wants to use g_log_set_default_handler(), it
should
require GLib 2.6.

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

Simple mechanism to silence midgard-core:

    static void null_log_handler(
                    const gchar *domain, GLogLevelFlags
log_level,
                    const gchar *message, gpointer data) {
            /* do nothing */
    }

    g_log_set_handler(
            MIDGARD_LOG_HANDLER, G_LOG_LEVEL_MASK,
            null_log_handler, NULL);

We should replace all explicit "midgard-lib" and
"midgard-core" log
domains strings in midgard-core with G_LOG_DOMAIN.

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

Depends on what MidgardSitegroup and MidgardLanguage are...

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development

"Jukka Zitting" <jukka.zittinggmail.com> wrote:

> Hi,

Hi,
 
> > 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.
> 
> I wouldn't be that strict. Use what best suits the
requirements. Using
> GObjects is no magic dust to make language bindings
easy, GObjects
> just provide a standard set of features 

Yes, and thus we should provide Midgard standards.

>(properties, signals, data
> attachments, inheritance, introspection, etc.) that is
well supported
> in a variety of environments. Using GObjects for stuff
that doesn't
> need those features (for example MidgardConnection
doesn't really need
> generic properties or introspection, but signals and
data attachments
> might be nice) is just extra work.

MidgardConnection has no properties , and that part of
GObject code requires 
much work. The rest must be written anyway. 
midgard_connection_close may be replaced with g_object_unref
then without 
any need to provide another API function. 

MidgardConfig has plenty of properties instead,  but my
point is that it should be 
easier to maintain in a long run. As Apache related
structure's member and as 
future tools like datagard written in PHP or maybe perl. 
 
> > > a) use g_log_set_default_handler() to handle
log messages from
> > > *all* log domains, or
> >
> > Yeah, but this is GLib 2.6 :/
> 
> You're already using it in src/config.c. In any case
we shouldn't be
> using either of the g_log_set functions in
midgard-core. If an
> application wants to use g_log_set_default_handler(),
it should
> require GLib 2.6.

damn me...
 
> > 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().
> 
> Simple mechanism to silence midgard-core:
> 
>     static void null_log_handler(
>                     const gchar *domain, GLogLevelFlags
log_level,
>                     const gchar *message, gpointer
data) {
>             /* do nothing */
>     }
> 
>     g_log_set_handler(
>             MIDGARD_LOG_HANDLER, G_LOG_LEVEL_MASK,
>             null_log_handler, NULL);

That doesn't work :/ 
Or I missed some little detail :/
 
> We should replace all explicit
"midgard-lib" and "midgard-core" log
> domains strings in midgard-core with G_LOG_DOMAIN.

What about "repligard" domain?
 
> > 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);
> 
> Depends on what MidgardSitegroup and MidgardLanguage
are...

GObjects. My point is still the same. Implement API which
may be used in 1.8.x and in 1.9/2.0.

Piotras

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Hi,

On 3/6/06, Piotras <ppinfoglob.com> wrote:
> > Simple mechanism to silence midgard-core:
> >
> >     static void null_log_handler(
> >                     const gchar *domain,
GLogLevelFlags log_level,
> >                     const gchar *message, gpointer
data) {
> >             /* do nothing */
> >     }
> >
> >     g_log_set_handler(
> >             MIDGARD_LOG_HANDLER, G_LOG_LEVEL_MASK,
> >             null_log_handler, NULL);
>
> That doesn't work :/
> Or I missed some little detail :/

Works for me. What's the problem?

> > We should replace all explicit
"midgard-lib" and "midgard-core" log
> > domains strings in midgard-core with G_LOG_DOMAIN.
>
> What about "repligard" domain?

It shouldn't be in midgard-core.

> > Depends on what MidgardSitegroup and
MidgardLanguage are...
>
> GObjects. My point is still the same. Implement API
which may be
> used in 1.8.x and in 1.9/2.0.

Obviously, but what GObjects? Are they MgdSchema objects for
midgard_sitegroup and midgard_language? Would I need to get
them from
the database first before passing them to
midgard_connection_set_...?
Can I just instantiate one and pass it to
midgard_connection_set_...
without creating the corresponding database record?

AFAIK midgard-core just needs to know the sitegroup and
language id
numbers internally. Why do we need to pass in full objects
when we
could just pass a string (guid or name) that uniquely
identifies the
sitegroup or language in question? (I'd rather not pass the
id number
directly, as we should avoid using them on the API level.)

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development

"Jukka Zitting" <jukka.zittinggmail.com> wrote:

> > > Simple mechanism to silence midgard-core:
> > >
> > >     static void null_log_handler(
> > >                     const gchar *domain,
GLogLevelFlags log_level,
> > >                     const gchar *message,
gpointer data) {
> > >             /* do nothing */
> > >     }
> > >
> > >     g_log_set_handler(
> > >             MIDGARD_LOG_HANDLER,
G_LOG_LEVEL_MASK,
> > >             null_log_handler, NULL);
> >
> > That doesn't work :/
> > Or I missed some little detail :/
> 
> Works for me. What's the problem?

All messages are logged unconditionally. 
 
> > > We should replace all explicit
"midgard-lib" and "midgard-core" log
> > > domains strings in midgard-core with
G_LOG_DOMAIN.
> >
> > What about "repligard" domain?
> 
> It shouldn't be in midgard-core.

It's defined when repligard is compiled , so I need two log
handlers for repligard.
 
> AFAIK midgard-core just needs to know the sitegroup and
language id
> numbers internally. Why do we need to pass in full
objects when we
> could just pass a string (guid or name) that uniquely
identifies the
> sitegroup or language in question? (I'd rather not
pass the id number
> directly, as we should avoid using them on the API
level.)

OK, I prefer guid. I will update header file soon.

Piotras

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Hi,

On 3/6/06, Piotras <ppinfoglob.com> wrote:
> > Works for me. What's the problem?
>
> All messages are logged unconditionally.

You are doing something wrong. Try the following:

----------
$ cat test.c
#include <glib.h>

#define G_LOG_DOMAIN "test"

static void null_log_handler(
                const gchar *domain, GLogLevelFlags
log_level,
                const gchar *message, gpointer data) {
}

int main() {
        g_log_set_handler(
                G_LOG_DOMAIN, G_LOG_LEVEL_MASK,
                null_log_handler, NULL);
        g_debug("debug");
        g_message("message");
        g_warning("warning");
        g_critical("critical");
        return 0;
}
$ gcc -o test test.c `pkg-config --cflags --libs glib-2.0`
$ ./test
----------

Outputs nothing, unless you remove the g_log_set_handler()
statement.

> > > What about "repligard" domain?
> >
> > It shouldn't be in midgard-core.
>
> It's defined when repligard is compiled, so I need two
log handlers for repligard.

Repligard is a standalone application so it should use the
default log
domain instead of a custom one. Starting from GLib 2.6
standalone
applications can just use g_log_set_default_handler() to
catch all log
messages. Before GLib 2.6 the procedure is to set up a
handler
(usually the same handler) for each log domain. Something
like this:

    /* Application log messages */
    g_log_set_handler(
            G_LOG_DOMAIN, G_LOG_LEVEL_MASK,
            my_handler, NULL);
    /* Midgard core log messages */
    g_log_set_handler(
            MIDGARD_LOG_DOMAIN, G_LOG_LEVEL_MASK,
            my_handler, NULL);

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development

"Jukka Zitting" <jukka.zittinggmail.com> wrote:

> Hi,

Hi,

> > All messages are logged unconditionally.
> 
> You are doing something wrong. Try the following:

OK, that works fine, just commited repligard's changes.
I tried with :

mgd->loglevel = mgd_parse_log_levels("warn");
g_log_set_handler(G_LOG_DOMAIN, mgd->loglevel,
             mgd_log_debug_default,
(gpointer)mgd->loglevel);

For every domain.

Piotras

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Piotras <ppinfoglob.com> wrote:

> OK, I prefer guid. I will update header file soon.

I updated MidgardConnection's header.

Few notes: 

1. I removed set_sitegroup as this should be done in
mgd_auth function
or other way for hosts. I am not sure if such feature should
be handled by such API.

2. I still keep set(get) loghandler. Of course we can remove
it if g_remove_loghandler 
doesn't need to be used.

3. loglevel is still kept as there should be possibility to
change loglevel from any level.
And such change should affect also midgard-core , which uses
the same connection 
with loglevel info.

Piotras

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Hi,

On 3/8/06, Piotras <ppinfoglob.com> wrote:
> 1. I removed set_sitegroup as this should be done in
mgd_auth function
> or other way for hosts. I am not sure if such feature
should be handled by such API.

OK. The connection sitegroup is always linked to the
connection user,
so it makes sense to provide an API just to set the
connection user
and have the sitegroup deduced from the connection user.

> 2. I still keep set(get) loghandler. Of course we can
remove it if g_remove_loghandler
> doesn't need to be used.
>
> 3. loglevel is still kept as there should be
possibility to change loglevel from any level.
> And such change should affect also midgard-core , which
uses the same connection
> with loglevel info.

-1. Let me repeat, midgard-core should *not* attempt to
handle the log
messages it creates. It is the task of the application that
registers
the log handler to determine the log level to be used.

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development

"Jukka Zitting" <jukka.zittinggmail.com> wrote:

> Hi,

> > 1. I removed set_sitegroup as this should be done
in mgd_auth function
> > or other way for hosts. I am not sure if such
feature should be handled by such API.
> 
> OK. The connection sitegroup is always linked to the
connection user,
> so it makes sense to provide an API just to set the
connection user
> and have the sitegroup deduced from the connection
user.

I have no idea how to set sitegroup from apache vhot and
anonymous request though ;)

> > 2. I still keep set(get) loghandler. Of course we
can remove it if g_remove_loghandler
> > doesn't need to be used.
> >
> > 3. loglevel is still kept as there should be
possibility to change loglevel from any level.
> > And such change should affect also midgard-core ,
which uses the same connection
> > with loglevel info.
> 
> -1. Let me repeat, midgard-core should *not* attempt to
handle the log
> messages it creates. It is the task of the application
that registers
> the log handler to determine the log level to be used.

Just easy, I still misunderstand something.

1. Loglevel 
Can I set debug or info loglevel from *php* level while
application started with warn leglevel then?
And use debug messages from core?

2. Loghandler
Should I use g_remove_loghandler when I change loghandler?
Or can I forget about it?

Both.
Can we have some generic GLogFunc in core so I shouldn't
worry about writing one GLogFunc
per one application?

Piotras



------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribemidgard-project.org
For additional commands, e-mail: dev-helpmidgard-project.org

Hi,

On 3/8/06, Piotras <ppinfoglob.com> wrote:
> > OK. The connection sitegroup is always linked to
the connection user,
> > so it makes sense to provide an API just to set
the connection user
> > and have the sitegroup deduced from the connection
user.
>
> I have no idea how to set sitegroup from apache vhot
and anonymous request though ;)

Good point. So we *do* need a
midgard_connection_set_sitegroup() method.

> 1. Loglevel
> Can I set debug or info loglevel from *php* level while
application started
> with warn leglevel then? And use debug messages from
core?

Yes. If we set up a log handler in midgard-php that routes
the
messages to the PHP log handler, then the level can simply
be
controlled with the PHP error_reporting() function.

> 2. Loghandler
> Should I use g_remove_loghandler when I change
loghandler? Or can I forget about it?

Easy, use the g_remove_loghandler() when you no longer want
to have
the messages sent to that log handler.

> Both.
> Can we have some generic GLogFunc in core so I
shouldn't worry about writing
> one GLogFunc per one application?

Yes, we can, but... There are hardly even two different
Midgard
applications that would have the same logging requirements.
Logging
under Apache is very much different from logging in a
standalone
application. A log handler is normally less than 20 lines of
code, so
I think the greater flexibility of not forcing a single
logging
mechanism on all clients greatly outweights the benefit of a
built-in
log handler.

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - infoyukatan.fi
Software craftsmanship, JCR consulting, and Java
development