apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Mixing Apache and Mozilla
Date Sat, 24 Feb 2001 10:32:07 GMT
On Fri, Feb 23, 2001 at 07:53:02PM -0800, Wan-Teh Chang wrote:
> There are obviously some misconceptions about NSPR which
> I have responded to in private email to avoid a flame war
> on this mailing list.

[ Thankfully, I think we're pretty immune to that here. new-httpd has a
  larger subscription base, but even there, I've only seen a few "real"
  flame wars in the past few years. Heated arguments, yes. Flame? Nope. ]

> It is also obvious to me that since
> both NSPR and APR have to support their current APIs, the
> only kind of "merger" that could happen is to implement one
> API on top of the other.  That is an interesting exercise
> but does not need to be done now.

Agreed. Due to licensing sub/superset issues, my preferred approach is NSPR
on top of APR. The NSPR could then be released under its (current)
GPL/NPL/MPL license without a problem. (*)

If we did APR over NSPR, then APR would pick up add'l restrictions from the
MPL (we'd choose that one, being the least restrictive). The ASF community
would not be extremely receptive to that (for better or worse; that is not
the discussive point here)

(*) once our v1.2 license is completed sometime this year; 1.1 conflicts
with the GPL, although we could fix that for an NSPR/APR bundle.

> Until someone implements one API on top of the other, using
> NSPR and APR in the same process has only two problems that
> I don't think are serious for most Apache users.
> 1. Larger binary size.  Disks and RAMs are only getting
>    cheaper so a modest code bloat should not be a problem
>    for a server box running Apache.

Or Subversion or ...  APR has some other users now :-). But the point is
quite valid!

> 2. Incompatible threading libraries.  This is not an issue
>    if native threads are used.  Native threads are available
>    on the latest releases of almost all the operating systems
>    capable of running Apache.

Again: valid point.

I believe that APR cannot use anything *but* native threads. I recall a push
for Pth compatibility somewhere along the line, for some codebase. I don't
recall the specifics, though.

In other words, APR is restricted to native threads, so an NSPR linked in
with APR would also need to use native threads.

> It would seem like a shame that Apache has to develop APR
> from scratch.

Past tense :-)  "had"  For all intents and purposes, APR is beta quality and
nearing a release. It is actually quite a bit more stable than the Apache
HTTPD Server.

> But writing new code is fun, and APR has the
> opportunity to learn from and avoid the mistakes and design
> flaws of NSPR.

That was one of the motivators, along with using the accumulated porting
knowledge of the Apache 1.3 code base.

> It is a shame that the MPL that NSPR is
> released under prevents the APR developers from using code
> in NSPR because a lot of knowledge and experience is embodied
> in the NSPR code base.  Some of that didn't come easy, such
> as the undocumented (or rather not well documented) features
> that we use after confirming with the OS vendors that they
> will continue to be suppported, the bug workarounds that
> we put in after days of debugging and studying the "knowledge
> base" articles of the OS vendors, and the collective experience
> of the five Netscape engineers who developed NSPR.

Agreed on all points. However, the original motivation for APR (license-
wise) was because NSPR was under MPL 1.0 at the time. There was no way we
could touch it until it moved to the new MPL 1.1 license. That dragged on
for several months before our team said "screw it" and just started APR. We
had motivated people who were willing to invest the time in code
duplication. Not an ideal scenario, but required.

Today, it would be more about licensing philosophy, rather than a need to
avoid the MPL license.

> But I am
> sure that with this group of highly skilled and motivated
> developers and the support many OS vendors give to ASF, APR
> will be a fine product.

We think so :-). Thanks.

> One good point that Jon Smirl made, which was often overlooked
> in the heated discussion, is that there are a lot of Mozilla
> technologies based on NSPR, such as XPCOM, NSS, and LDAP SDK,
> that can be used in other products.  As I pointed out above, on
> platforms with native threads, there is no technical problem
> using these NSPR-based technologies with APR.  The only blocker
> would again be the MPL under which these open source technologies
> are released under.

The ASF is actually pretty fine with the MPL. But only for "third party"
libraries. While we may include a foreign codebase in our CVS tree, it would
only be present for convenience and redistribution. None of the
ASF-copyrighted code can/would fall under the MPL. Thus, the ASF cannot
assist in the continued development/maintenance of those projects. But we
certainly can use them!

Personally, I'd like to see XPCOM become available within the ASF code
space. I'd like to use it to development Apache components in Python.

> APR has the opportunity and potential to be better than NSPR.
> I'd love to see that happen.  My best regards.

Potential.

We don't have NSPR's breadth at the moment. We also don't have the broad
exposure/usage. Those are certainly inhibitive factors (relatively
speaking).

We'll just have to see what happens :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message