hi,
On Thu, Aug 04, 2005 at 11:51:34AM -0400, Charles Fry wrote:
> Here are some basic thoughts based an a quick read:
>
> Webapps Policy Manual
> 1.3: Lists DB App Policy twice
whoops, fixed.
> 3.1: Cached and regenerated application data should go in
> /var/cache/PACKAGE
this is specified in the db document, so i changed the listing to
be less ambiguous.
> 3.2.1: Config files generated via a web interface should exist
> in /etc, inasmuch as they can still be edited by hand
this is something we'll need to have a more thorough discussion about.
typically, when config files are overwritten by programs they should go
in /var/lib and then be referenced via config files in /etc. something
like
/var/lib/webapp/config.php (root:www-data/664):
<?php
$something = "foo";
$something_else = "bar";
?>
/etc/webapp/config.php (root:www-data/644):
<?php
# get application configured settings from here.
include_once("/var/lib/webapps/config.php");
# alternatively comment that out and uncomment the following
#$something = "foobar";
#$something_else = "farsar";
but maybe that's overkill. we should probably create a section for
stuff like this as "points for further discussion" and see what the
larger community thinks. if the consensus is that it's okay for
www-data writable config files in /etc, i'll add support to
webapps-common for specifying which config files should be
managable by the webapp, and then the admin can be prompted whether
or not to install them writable as part of the install process.
> 5.1.1: I must have joined the list after this was discussed, but
> it seems to me that creating symlinks is far more portable
> (accross httpd servers) than creating Alias directives. Have
> you talked about the possibility of prompting for the
> document root, with /var/www as the default, for example?
i was hoping that we could solicit some feedback from the non-admin
httpd maintainers to get an idea of how many servers did and didn't
support such a feature. i think the general consensus is that we
should be agnostic of the documentroot and not mess around with files
and symlinks in there if at all possible.
> 5.2: Should include HTTP_HOST environmental variable as well.
> Perhaps we should recommend explicitely facilitating support
> for multiple instances.
added reference to that variable as well. now, what about multiple
instances running out of the same virtualhost but different
subdirectory?
> PHP Policy Draft
>
> 4.1.1: Should NOT be of the form php-pear-PEARLIBRARYNAME.
allright. so we have:
official php:
phpPHPVERSION
phpPHPVERSION-cli
phpPHPVERSION-cgi
phpPHPVERSION-MODULE
pear and non-pear php libraries:
php-MODULE
precompiled php extensions:
?
does that sound right?
> 4.1.2: "XXX: does this conflict with piotr's recommendation for
> having pear work only in /usr/local?": yes, but I think that
> he is wrong about that. ;-)
having thought about it, there's probably some combination of cmdline
params that could be used to have pear work out of the /usr/share
repository when installing prepackaged pear modules, and have it
otherwise default to working out of /usr/local/share/php otherwise.
thanks,
sean
--
Attachment:
signature.asc
Description: Digital signature