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

Hi,

On 2/18/06, Piotras <[email protected]> wrote:
> What should I do with:
>         * person object instance created during request
>         * loglevel set during request
>         * sitegroup
>         * lang
>         * probably logfile

I'm a bit confused about this vhost/request configuration stuff you
refer to. In my mind the configuration mechanism is used to set up the
database connection and related options like the blob directory. Once
we have an initialized MidgardConnection, the configuration is no
longer used except implicitly through the Midgard API.

Things like user authentication (I assume that this is the what you
mean by the person object instance) and sitegroup/lang selection
happen dynamically based on request information sent by the client.
That information is not related to the configuration mechanism, as it
is managed with the separate mgd_auth() and mgd_set_lang() API
functions.

As I mentioned in the other message, log handling should also be
separate from configuration handling in midgard-core.

> So probably dcfg ( rather rcfg ) structures could have two members , two MidgardConfig.
> Real configuration pointer and pointer to config which is initialized only for request time.

I think we could do with just the configuration name being a part of
the Apache dcfg. Apache-specific things like the root file or page
cache locations would of course also need to be in the dcfg.

> And another question ;)
> Should we have MidgardConnection object or just Midgard ?

I think MidgardConnection is better as it represents a connection to a
specific Midgard database. It is possible that we later on want to use
a global Midgard resource context object instead of hidden global
variables for things like global schema information, etc.

BR,

Jukka Zitting

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