rahul wrote: > > 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? 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 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. 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. What's the use case where a customer decides they reall want SUNWPython-apache on their system but don't want to see the corresponding module bits on their system? -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
