| > These modules do not have limitations on the above. This is just FYI | | Ruby doesn't seem to have delivered a 64-bit version yet, so if(?) | mod_ruby embeds the interpreter in the apache process, how does this | project support it in a 64bit apache process?
How is this different from the mod_perl http://sac.sfbay/PSARC/2007/169/materials/ApacheOnePager.txt As far as I know, we dont deliver 64 bit mod_perl yet since perl does not deliver 64 bit yet, Nor does the latest Apache ARC specify any limitations of that sort other than not putting 64/mod_perl.so in its modules. | The ruby interpreter isn't thread-safe and, IIRC, neither is the | python one so how does it avoid problems when multiple worker threads | are accessing the same interpreter? At least with ruby, even a big lock | around the interpreter wasn't enough in the past (perhaps it has improved?) It is still unstable, but works. http://ml.osdir.com/apache.mod-ruby/2004-09/msg00033.html I do not know all the caveats, but no where in the documentation is it mentioned that only Prefork is supported. more over, it does quite a bit of things if the MPM is not prefork (mod_ruby.c). | > It clearly states that it is interested in the interfaces between | > components rather than the implementation details. The things like 64 | > bit support for the present, and MPMs currently supported are | > implementation artifacts that do not have any thing to do with either | > architecture or the interface | Filing as a Fast Track does not exempt a project from any of the usual | requirements of a full case. While you're not required to file, say, | the 20Questions, it is expected that all interesting information is | documented in the case. Since a Fast Track must be "obvious and | noncontroversial", most things should have obvious answers but | anything that doesn't is to be explicitly documented. There seems to be a disconnect in what are the usual requirements. (As pointed out in the case of Apache and perl above). From my reading (as mentioned in the previous mail) ARC does not ask for all the things that you want to put in, and states that it is not interested in those. | Another aspect to keep in mind when writing Fast Tracks is that the | content must be self-contained to an audience of senior engineers who | don't necessarily have any previous exposure to the very specific | topic of each project. The onus is on the project team to document all | interactions in sufficient detail to make it meet the "obvious and | noncontroversial" bar. | | > Well, the same thing applies to supplying apache and the modules. what | > if apache is upgraded but modules are not? I think it is useful to split | > the library component and the native component also because it is | > treated as two independent components by the upstream project and are | > delivered into two different locations. I will add it this to the ARC case. | | I'm not yet convinced there is a good reason for the split, | implementation detail usually doesn't count. Package granularity | should in most cases be driven by customer needs. Upstream believes that there is case for splitting up the installation into two parts if necessary, I believe it is driven by customer needs. At the very least I would believe them to be better judges in this case. | What's the use case where a customer decides they really want | SUNWPython-apache on their system but don't want to see the | corresponding module bits on their system? see above. I tend to believe that decoupling is a good decision in packages so long as a system for installing dependent packages if necessary is in place. (IPS?) rahul -- 1. e4 _
