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

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

> Hi,

Hi,


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

Relax, I am not thinking about mgd->lang like members usage , I am really far from it.
 
> 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.

I comment it at the end.
 
> 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.

As long we do not depreciate Apache directives. For now I know we want to do this.
 
> > 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.

I think such decision should be made before midgard connection is implemented.

If I am to get request's lang with mgd_set_lang() API, what should I really reffer to?

mgd_set_lang(MidgardConnection) ?
mgd_set_lang(MidgardConfig) ?
mgd_set_lang(Midgard) ?

My point is that I do not think I want to follow connection handler in extension like midgard-php.
Maybe I should initialize Midgard object when rcfg exists and use its properties and create
new instance while using php-cli to write the same code for both?

I know that I should assign midgard connection handler to midgard , but I want to underline 
that midgard-php needs something more than connection handler and midgard config.
Either global midgard object available during request or some mixed connection&config functionality.

Piotras