There are obviously some misconceptions about NSPR which I have responded to in private email to avoid a flame war on this mailing list. 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.
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. 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. It would seem like a shame that Apache has to develop APR from scratch. But writing new code is fun, and APR has the opportunity to learn from and avoid the mistakes and design flaws of NSPR. 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. 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. 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. APR has the opportunity and potential to be better than NSPR. I'd love to see that happen. My best regards. Wan-Teh
