rahul wrote:
>
> 1.1. Introduction
>
> This project delivers Apache modules mod_python and mod_ruby
> to the Apache2 (PSARC/2007/586) in OpenSolaris.
Are either/both of these modules supported in both worker & prefork MPMs?
Please document any limitations (if any).
> This project delivers the shared libraries of 32 bit and 64 bit
> into /usr/apache2/2.2/libexec and /usr/apache2/2.2/libexec/${ISAINFO}/
> directories of apache. This is in keeping with the approach taken
> by the Apache2 integration project for OpenSolaris (PSARC/2007/586).
IIRC there's not 64bit ruby so will that work?
> 4. Packaging and Delivery
>
> The modules will be split into two parts. One the apache part which
> consists of modules loadable into apache, and another the scripting
> library part.
>
> The apache modules will be delivered under the cluster SUNWCapch22m.
> This cluster will carry SUNWapch22m-python and SUNWapch22m-ruby.
>
> The scripting library part of mod_python will be delivered under
> SUNWPython-apache.
>
> The scripting library part of mod_ruby will be delivered under
> SUNWruby18-apache.
That seems disjoint.. Is there an expected use case where a python
user wants only SUNWPython-apache but not the associated module?
Why the seemingly odd separation here?
> 5.1. Interface Stability
>
> The interface stability of both of these modules are Volatile as
> these are controlled by external organisations over which Sun has
> no control. The specific researches regarding stability of each
> module are captured below.
As in previous cases, that's not true. The stability classification is
not driven by who controls it, so remove that (the classification
itself may or may not be Volatile, but provide a proper reasoning for
the decision).
> 5.3. Exported Interfaces
This looks just like a list of files...
A list of of files is not the exported interfaces. Aren't many if not
all of these files project private implementation detail?
Are each and all of these *.py and *.rb files truly public interfaces
which the developers will be loading directly?
Isn't there a documented API they'd be using?
To give a somewhat related example, if you were writing the exported
interface table for Java Servlets you would not list a bunch of
*.class files. Instead, you would document the public interfaces, like
HttpServlet.doGet(...)
HttpServlet.doPost(...)
...
The things in the Addendum sections seem more like exported
interfaces, though I'm not familiar enough with mod_python and
mod_ruby to tell which ones are.
Other things that are exported interfaces are the package names.
Some file paths are also exported interfaces, but only those which you
intend to document for user consumption. For example the path & name
of the config files are exported interfaces since we'd document where
they are so users can edit them.
(The full list of files is useful to include BTW, but stick it into an
appendix so it is available for reference but out of the way.)
--
Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
