MidgardConfig comments (Was: Automake and directories)

> Hi,

Hi,

> My suggestion would be to pass just a generic
configuration "name" as
> an argument and let the implementation decide the
location and name of
> the corresponding configuration file. A possible
Windows port might
> well want to use a different directory layout and
naming convention.

OK. Should we additionally check for existing possible
extension in name?

>> ok , just tell me how can I know using three log
files that this query is executed
>> before this php function and after this apache
call?
>
> In fact the situation at the moment is that you have
three different
> log files: the Apache error log, the Midgard log, and
the MidCOM log.
> It's possible to have them all pointing to the same
place but
> currently that needs special attention. It would be
better if all the
> logs would go to the Apache log and follow the Apache
LogLevel by
> default, but you could still point the logs elsewhere
if you really
> wanted to.

Yes, I can not focus on log files only now. midgard-php and
midgard-core
use the same file.
How do you find Apache log error used in both apache&php
and php-cli environments?

Your proposal for g_log2ap wrapper is very good, but far
from being usefull
on php level. For such environment I need some core's log
handler.
Either initilized or supported by core.

> To illustrate my point I found your own comment
(carelessly taken out
> of context  from
December: "Typical midcom log file is empty and I
> have no idea how to define new log file or even log
level." (See
> http://permalink.gmane.org/gmane.comp.web.midgard.de
vel/6345)

Yes, and I know how I wrote that.
My perfect midgard log file should log everything from
midcom to core.
That should be quite easy to write g_log like function for
midgard-php.
The question is if it could be implemented something else
than only in midgard-php.

I understand your point of view but I  can not count how
many times I asked
users about setting 3~4 different log files.

Piotras


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

Hi,

We should start turning this conversation into documentation
in the
code and on the wiki. There's been much talk but not many
hard
decisions. We should nail down at least the following (with
my
suggestions in parenthesis):

0) Roadmap for the new configuration mechanism
   (beta in 1.8, stable in 1.9)

1) Format of the configuration files
   (the GKeyFile format, perhaps using the real GKeyFile
parser later on)

2) Location of the configuration files
   (SYSCONFDIR/midgard/conf.d/*.conf and
$HOME/.midgard/conf.d/*.conf)

3) The API to read and construct configuration objects
    (See my MidgardConfig proposal a few messages ago)

4) The API to use the configuration to create a connection
    (See my MidgardConnection proposal a few messages ago)

On 2/19/06, Piotras <ppinfoglob.com> wrote:
> OK. Should we additionally check for existing possible
extension in name?

Better if we didn't. If someone asks for configuration
named
"foo.conf", then we should look for a file named
"/etc/midgard/conf.d/foo.conf.conf". 

> Yes, I can not focus on log files only now.

OK. We can postpone the log discussion to another thread.

BR,

Jukka Zitting

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

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

> Hi,
> 
> We should start turning this conversation into
documentation in the
> code and on the wiki. There's been much talk but not
many hard
> decisions. We should nail down at least the following
(with my
> suggestions in parenthesis):
> 
> 0) Roadmap for the new configuration mechanism
>    (beta in 1.8, stable in 1.9)

http://www.midgard-project.org/development/roadmap/1-8/
http://www.midgard-project.org/development/roadmap/1-9/
 
> 1) Format of the configuration files
>    (the GKeyFile format, perhaps using the real
GKeyFile parser later on)

1. I already fixed boolean values. GLib supports also 0 and
1 as values.
One should read sources to know this, so we support true or
false now. 
2. I am not sure about comments real syntax.
3. I am not sure if it's worth to write special code to
parse values ( stripping spaces and duplicated equal signs )
4. Libgda config file location?
 
> 2) Location of the configuration files
>    (SYSCONFDIR/midgard/conf.d/*.conf and
$HOME/.midgard/conf.d/*.conf)

Can we define it in configure script and statically in
header file?
I mean only $sysconfdir. I do not follow  XDG Base Directory
logic here.
 
> 3) The API to read and construct configuration objects
>     (See my MidgardConfig proposal a few messages ago)

That's fine. However I would likt to keep existing
midgard_config_read_file
instead of midgard_config_read. 
And I am not sure about such thing:

MidgardConfig *midgard_config_new(void);
MidgardConfig *midgard_config_read(const char *filename,
GError **error);

If both returns MidgardConfig , why do you need the first
one , if you do not pass it as config_read
parameter? Shouldn't it be :

MidgardConfig *midgard_config_new(void);
gboolean midgard_config_read(MidgardConfig *config, const
char *filename, GError **error);

?

Of course midgard_config_new(void) could be used directly
with midgard_connection as initialized 
MidgardConfig which is set internally by MidgardConnection
implementation.

> 4) The API to use the configuration to create a
connection
>     (See my MidgardConnection proposal a few messages
ago)

That's fine too. I will read *full* midgard_connection API
proposal and will commit as standalone
( not used ) header file. I would like to start using
doxygen on nathan next week , so we can have 
good reference url then.

> > Yes, I can not focus on log files only now.
> 
> OK. We can postpone the log discussion to another
thread.

Absolutely. This feature is *very* important and I need it
*now* usable in HEAD.

Piotras

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

Hi,

On 2/24/06, Piotras <ppinfoglob.com> wrote:
> > 0) Roadmap for the new configuration mechanism
> >    (beta in 1.8, stable in 1.9)
>
> http://www.midgard-project.org/development/roadmap/1-8/
> http://www.midgard-project.org/development/roadmap/1-9/

Excellent, agreed.

> > 1) Format of the configuration files
> >    (the GKeyFile format, perhaps using the real
GKeyFile parser later on)
>
> 1. I already fixed boolean values. GLib supports also 0
and 1 as values.
> One should read sources to know this, so we support
true or false now.
> 2. I am not sure about comments real syntax.
> 3. I am not sure if it's worth to write special code
to parse values ( stripping spaces and duplicated equal
signs )
> 4. Libgda config file location?

It's OK if we say that we use the GKeyFile syntax, but that
there
might be some minor inconsistencies before the real GKeyFile
parser is
used. The important thing is that people can use GLib to
read and
modify the config files without worrying too much about the
syntax
differences.

4. Libgda config files are named SYSCONFDIR/libgda/config
and
$HOME/.libgda/config.

One more thing I'm wondering about the Midgard
configuration file
format... Now each Midgard database is configured in a
separate
configuration file with a single [Database] section. An
alternative
would be to have just one configuration file with multiple
sections
named by the configured databases. This would allow us for
example to
have a nice global configuration section. Something like
this:

----------
$ cat /etc/midgard/midgard.conf
[global]
Username=midgard
Password=xyz

[midgardstaging]
Name=midgardstaging
Blobdir=/custom/path/for/blobs/midgardstaging

[midgardlive]
Name=midgardlive
Blobdir=/custom/path/for/blobs/midgardlive
----------

We could also support the conf.d directory like this:

----------
$ cat /etc/midgard/conf.d/midgardtest.conf
[midgardtest]
Name=midgardtest
Blobdir=/custom/path/for/blobs/midgardtest
----------

> > 2) Location of the configuration files
> >    (SYSCONFDIR/midgard/conf.d/*.conf and
$HOME/.midgard/conf.d/*.conf)
>
> Can we define it in configure script and statically in
header file?
> I mean only $sysconfdir. I do not follow  XDG Base
Directory logic here.

The configure script is a good place to do that.

> > 3) The API to read and construct configuration
objects
> >     (See my MidgardConfig proposal a few messages
ago)
> [...]
> MidgardConfig *midgard_config_new(void);
> gboolean midgard_config_read(MidgardConfig *config,
const char *filename, GError **error);

That looks even better than the what I proposed. I'd
actually like to
avoid the direct filename reference in the API and even the
concept of
"reading" a file. It might be better to
"load" a named configuration,
like this:

------------------------------------------------------------
/**
 * Creates an empty Midgard configuration object. The
application
 * can load an existing configuration with
midgard_config_load() or
 * manually fill in the configuration parameters with
g_object_set().
 *
 * \return empty Midgard configuration object
 */
MidgardConfig *midgard_config_new(void);

/**
 * Loads the named configuration to the given Midgard
configuration object.
 * The named configuration is loaded using the standard
Midgard configuration
 * mechanism and the loaded configuration options are
written to the
 * given configuration object.
 *
 * Returns \c TRUE if the named configuration was loaded
successfully.
 * If the named configuration was not found or another error
occurred,
 * then the \c error placeholder (if not \c NULL) is
filled with an error
 * message and the return value is \c FALSE.
 *
 * \param[inout] config the configuration object
 * \param[in]    name   name of the configuration to load
 * \param[out]   error  placeholder for possible error
messages, or \c NULL
 * \return \c TRUE if the named configuration was loaded
successfully,
 *         \c FALSE otherwise
 */
gboolean midgard_config_load(
        MidgardConfig *config, const char *name, GError
**error);
----------

This would make the API future-safe even for things like
having
Midgard configuration stored in the Windows Active
Directory!

BR,

Jukka Zitting

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

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

> It's OK if we say that we use the GKeyFile syntax, but
that there
> might be some minor inconsistencies before the real
GKeyFile parser is
> used. The important thing is that people can use GLib
to read and
> modify the config files without worrying too much about
the syntax
> differences.

File syntax was initially parsed by GKeyFile API so there
shouldn't be any inconsistencies. 
If we agree that file syntax and usage is in beta stage ,
then we shouldn't worry about 
"backward" compatibility in 1.9.
Especially when you think about database vs libgda
configuration. 
 
> One more thing I'm wondering about the Midgard
configuration file
> format... Now each Midgard database is configured in a
separate
> configuration file with a single [Database] section. An
alternative
> would be to have just one configuration file with
multiple sections
> named by the configured databases. This would allow us
for example to
> have a nice global configuration section. Something
like this:

Yes, but I wonder about real configuration file usage and
future sections.
We can provide such sections:

[Database]

#The name of libgda configuration file
Name=midgard

[Filesystem]

# var directory path
Var=/var/local/midgard/
Usr=/usr/local/midgard

#more

[MidgardUser]

Username=piotras
Password=secret
Sitegroup=somesg

#more and more

This file may be real huge one then. 

All in all I think the idea is good.

I do not comment API because it's good and depends on file
format implementation.

Piotras

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

Piotras <ppinfoglob.com> wrote:

> > 4) The API to use the configuration to create a
connection
> >     (See my MidgardConnection proposal a few
messages ago)
> 
> That's fine too. I will read *full* midgard_connection
API proposal and will commit as standalone
> ( not used ) header file. I would like to start using
doxygen on nathan next week , so we can have 
> good reference url then.

http://midgard.tigris.org/source/browse/midgard/src/cor
e/midgard/midgard/midgard_connection.h?rev=1.1&view=mark
up

Piotras

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

Hi,

On 2/27/06, Piotras <ppinfoglob.com> wrote:
> http://midgard.tigris.org/source/browse/midgard/src/cor
e/midgard/midgard/midgard_connection.h?rev=1.1&view=mark
up

Cool, thanks! See my comments in another message.

BR,

Jukka Zitting

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

Piotras <ppinfoglob.com> wrote:

> I would like to start using doxygen on nathan next week
, so we can have 
> good reference url then.

Daily docs:
http://www.midgard-project.org/api-docs/midgard/core/h
tml/

Piotras

 

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

Hi,

On 2/28/06, Piotras <ppinfoglob.com> wrote:
> Daily docs:
> http://www.midgard-project.org/api-docs/midgard/core/h
tml/

You're the best! Could we also generate static API docs for
the
releases in something like
.../api-docs/midgard/<version>/

BR,

Jukka Zitting

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

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

> Could we also generate static API docs for the
> releases in something like
.../api-docs/midgard/<version>/

That's an idea! After 1.8 ;)

Piotras

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