On Thu, 22 Feb 2001, Jon Smirl wrote: > XPCOM is a very interesting technology that allow the mixing of modules > written in C, Java, Javascript and Python across all of the Mozilla > target platforms (Windows, Linux, BEOS, Max, Unix, etc). XPCOM is a > portable version of Microsoft's COM. > > http://www.mozilla.org/projects/xpcom/ > > XPCOM could be used to replace Apache's module system. XPCOM is cross > platform and language neutral. I especially like the ability to call > Java in-process. XPCOM is built on top of NSPR, Mozilla's portable > run-time base. My desire to efficiently use XPCOM with Apache is one > reason I'd like to see Apache use NSPR and merge memory management > schemes. > > http://www.mozilla.org/projects/nspr/reference/html/index.html > > I've built a test module that uses Apache for the front-end and > Mozilla's XPCOM for the back. I'm pleased with the features and > performance. I can continue to use XPCOM from a module without changing > Apache but I'd like to see this technology become more mainstream. > > What's everybody's opinion on this? Let's ignore the license issues for > now, if there is technical agreement then I'm sure the license issues > can be worked out. After all these are both freely available, open > source projects.
There is a problem with ignoring the license issues, the license issues are a real issue for a lot of people on this list. There is also the problem that neither project can really just pick up and start over with their API's. I would be interested in bringing the two projects closer together, and trying to merge things where possible. NSPR has some very interesting APIs that would be cool to merge with APR. However, the memory management functions is not one of those areas IMHO. The pools implementation that APR uses is very closely tied to Apache and APR. If we ported Apache to NSPR, all we would do, is put the pools over NSPR's PR_malloc calls, as Dean did originally. I do not believe either team is interested in dropping support for their current projects. Both APR and NSPR would like to continue to move forward, at least for now. At least that is my impression. What I wonder is, is there anything that we can do to move the two projects closer together, so that at some point in the future, the two projects may be able to merge? If and when the projects merge, that would mean figuring out a way to be able to wrap the resulting API with macros that are backwards compatible for ecah project. That is a problem to solve later. The problem to solve now, is to determine if the APR and NSPR developers are at all interested in trying to move the two projects closer together. If not, we can end this now. If so, and this is what I am hoping for, let's stop talking about ending either project (that isn't going to happen immediately), let's instead talk about how we can move the two closer. Would NSPR be interested in any code from APR, would APR be interested in code from NSPR? Does it make sense to merge the two mailing lists (BTW, this message should be copied to the NSPR list, and all resulting messages should go to both as well)? Does it make sense to design future work together? We also need to tackle the license issues. First let's answer the questions in the previous paragraph. Then we need to look at licenses. If we can resolve all of those issues, then we can begin to actually work together. This is not going to be a fast process. Nobody should think that if we start this today, the two code bases are going to be merged by year's end. I don't believe it will go that fast, and it could be stalled and/or stopped at just about any time. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
