| > 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).
Aren't these limitations that may get cleared in the future if they
exists? Being an Architectural review, I do not see why we should be
adding these. I would think that the correct place to document them
would be in the bugster.
|
| > 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?
See the above. I have some reservations as to whether ARC case is the
correct place to document it. IMHO Arc cases should not act as a sink
of all transient information. rather they should document things that
should remain true during the entier life of the program as far as possible.
| > 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?
because there is a chance that the language library gets updated with out
the module or the other way round. With this approach, we can let user
update only those components necessary.
| > 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).
This was what you had suggested on the previous cases.
http://opensolaris.org/os/community/arc/caselog/2008/090/onepager/
I have captured the reasoning correctly in the paragraphs under 5.1 (As
you had suggested for the earlier case.)
| > 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?
The answer to all the above is that I have added the documented complete
APIs as extra arc materials as documented in 5.1.1 and 5.1.2 please do
refer to these.
| 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.)
I will move the relevant sections under 5.1.1 and 5.1.2 which states
that the full list of documented APIs are available as ARC materials
to Exported Interfaces section if that is what you mean?
rahul
