This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
From: Rich <scriptyrich@yahoo.co.uk>
To: mason-users@lists.sourceforge.net
Subject: [Mason] Mason framework services: How do you handle reading and sharing configuration data?
Date: Sun, 14 Jul 2002 20:40:24 +0100
Hi everyone,
Following on from my last post: 'RFC: Adding support services to Mason', I'm
going to ask a number of questions regarding the various services I would
like to add to the Mason framework - please note this would be achieved by
subclassing ApacheHandler, would not form part of Mason itself, and would in
no way be linked to the Mason development team.
I would love some constructive feedback, both how to and how not to do
things, and hope to build this into proof of concept code that might be
useful to less experienced Mason developers, a group I firmly count myself in.
So, covering the simplest issue first:
QUESTION 1: How do you handle reading and sharing configuration data in your
Mason powered apps/sites?
Implementations that worked.
Implementations that failed.
Performance issues.
Security issues.
Anything else I've omitted.
I look forward to your comments - if you don't wish to post here, please
email me directly at scriptyrich@yahoo.co.uk
===
To: mason-users@lists.sourceforge.net
Subject: Re: [Mason] Mason framework services: How do you handle reading and sharing configuration data?
From: David Dyer-Bennet <dd-b@dd-b.net>
Date: 14 Jul 2002 17:39:52 -0500
Rich <scriptyrich@yahoo.co.uk> writes:
> QUESTION 1: How do you handle reading and sharing configuration data in your
> Mason powered apps/sites?
>
> Implementations that worked.
> Implementations that failed.
> Performance issues.
> Security issues.
> Anything else I've omitted.
I'm currently using a mason component outside the web root that I
bring in when I need it. It returns a single hash that has all the
values I want configurable in it. This seems to "work" so far (site
in development, not deployed yet; got bad performance problems but I
believe they're database related, not related to accessing
configuration info).
(Some things that I've done as "configuration" variables in smaller
sites are just database content in this larger fully dynamic site.)
I originally wanted to have a straight perl component that contained
configuration and private methods for the site, but ran into problems
getting INC set usefully in a multiple-virtual-mason environment; I'll
call that a failure.
===
From: James G Smith <JGSmith@TAMU.Edu>
To: scriptyrich@yahoo.co.uk
Subject: Re: [Mason] Mason framework services: How do you handle reading and sharing configuration data?
Date: Sun, 14 Jul 2002 22:18:15 -0500
Rich <scriptyrich@yahoo.co.uk> wrote:
>Hi everyone,
>
>Following on from my last post: 'RFC: Adding support services to Mason', I'm
>going to ask a number of questions regarding the various services I would
>like to add to the Mason framework - please note this would be achieved by
>subclassing ApacheHandler, would not form part of Mason itself, and would in
>no way be linked to the Mason development team.
>
>I would love some constructive feedback, both how to and how not to do
>things, and hope to build this into proof of concept code that might be
>useful to less experienced Mason developers, a group I firmly count myself in.
>
>So, covering the simplest issue first:
>
>QUESTION 1: How do you handle reading and sharing configuration data in your
>Mason powered apps/sites?
>
> Implementations that worked.
> Implementations that failed.
> Performance issues.
> Security issues.
> Anything else I've omitted.
Currently, I am developing using the Uttu module (site temporarily
unavailable until I get in the office tomorrow -
http://uttu.tamu.edu/). I wrote it to handle uri<->filename
translations and handler configuration so I wouldn't have to remember
how to write my handler.pl each time. It also allows me to make
arbitrary modifications to the document tree or the sitemap without
one affecting the other.
Uttu itself is not specific to Mason, but it has code to create a
Mason handler and hand off content handling to that handler. It uses
AppConfig to read the configuration file and store that information
during server startup. It makes this information available to the
framework and the application.
A framework is a basic collection of files (for example, an
autohandler and associated Mason components to handle certain tasks)
and Perl modules. One of the Perl modules handles the core
configuration of the framework -- it defines what keys are allowed in
the configuration file, for example. The autohandler coordinates the
services provided by the framework (authentication, authorization,
etc.).
Each application that works within a given framework then is a
collection of Mascon components and Perl modules (similar to
controller/model). The Perl modules define what should appear in the
configuration file read by Uttu (based on the framework and the
framework calling the appropriate modules).
How does this perform? I don't know yet. It seems to do okay for a
low-traffic site, but then, almost anything does okay on such a
site. This was also all developed with Mason 1.05, before
subclassing.
Where am I wanting to go? Add an AxKit handler to Uttu so I can use
Mason (controllers) to generate XML using TT2 templates (views) :/ I
think the above configuration method will pale in comparison to how
inefficient the rest of the site may be. Something that is done only
once during server configuration can be allowed some inefficiencies.
===
From: Ilya Martynov <ilya@martynov.org>
To: scriptyrich@yahoo.co.uk
Cc: mason-users@lists.sourceforge.net
Subject: [Mason] Re: Mason framework services: How do you handle reading and sharing configuration data?
Date: 15 Jul 2002 12:39:21 +0400
>>>>> On Sun, 14 Jul 2002 20:40:24 +0100, Rich <scriptyrich@yahoo.co.uk> said:
R> So, covering the simplest issue first:
R> QUESTION 1: How do you handle reading and sharing configuration
R> data in your Mason powered apps/sites?
R> Implementations that worked.
R> Implementations that failed.
R> Performance issues.
R> Security issues.
R> Anything else I've omitted.
In my project I use singleton to represent whole application. I have
class App which is facade to all other application resources including
config object.
Config object is instance of AppConfig (see CPAN). It is created
during mod_perl server startup and all config files are parsed during
server startup.
Example code of use config object usage:
package SomePackage;
# export sub app() which gives access to instance of App class
use App qw(app);
sub some_method {
my $self = shift;
...
# get data from config
my $value = app->config->get($key);
...
}
Performance issues: nearly none. Config files are parsed only during
mod_perl server startup. Accesses to config data via config object
methods are fast enough. I.e. profiling showed that other parts of
application are most time consuming so perfomance of config API is out
of concern.
Security issues: I guess we are talking about Unix. In reality there
is nothing mod_perl specific here. In short in most Unix and Unix-like
systems process can get access to *any* data of other processes
running with same UID. So security policy is very simple: partition
system using different UIDs. For example if need to run two mod_perl
sites with some private data then run them in separated mod_perl
servers under different UIDs. Obviously any files with private data
must be have permissions like 0600 (or may be 0640 if there are group
which should have access to them too).
===