apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: Mixing Apache and Mozilla
Date Wed, 21 Feb 2001 22:09:03 GMT
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                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------



Mime
View raw message