[Webapps-common-discuss] webapps-common/doc Webapps-Policy-Manual-DRAFT.txt,1.15,1.16

Update of /cvsroot/webapps-common/webapps-common/doc
In directory haydn:/org/alioth.debian.org/chroot/home/users/seanius/tmp/cvs-serv16505

Modified Files:
	Webapps-Policy-Manual-DRAFT.txt 
Log Message:
more from sean

Index: Webapps-Policy-Manual-DRAFT.txt
===================================================================
RCS file: /cvsroot/webapps-common/webapps-common/doc/Webapps-Policy-Manual-DRAFT.txt,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -d -r1.15 -r1.16

--- Webapps-Policy-Manual-DRAFT.txt	11 May 2005 03:56:05 -0000	1.15
+++ Webapps-Policy-Manual-DRAFT.txt	12 May 2005 00:19:33 -0000	1.16
@@ -280,7 +280,8 @@
 3.2.2 Registering and unregistering a php module
 
 FIXME sukria : should such a piece of code be provided by a webapps-common package?
-FIXME sean : same question as apache conf.d: symlinks or files?
+FIXME sean : same question as apache conf.d: symlinks or files?  i'll assume
+             symlinks below
 
 Applications extending the abilities of php via add-on php modules should
 do so by placing symbolic links to any any relevant configuration files
@@ -288,12 +289,12 @@
 example).  Editing the contents of php.ini files directly is strongly
 discouraged and should only be done if it is not possible to make changes
 via the previously described method.  In such cases, packages must not
-do so without prompting the admin, and the default response for such
-prompting should be "false".
+do so without first prompting the admin, and the default response for such
+a question should be "false".
 
 Upon package removal, packages can de-register themselves by simply
 removing the symbolic link in the php.d directory (this makes seperating
-de-activation from configuration purging much cleaner).
+de-activation from configuration purging possible).
 
 FIXME sukria: 
   Those piece of code sould be provided by our webapps-common package. The



