94r0kp$[EMAIL PROTECTED]">I get that, and I'll bring it up with [EMAIL PROTECTED] -- we can certainly make xpcom.mozilla.org and point it anywhere in our website we like.I think the idea was more along the lines of having the Mozilla organization host xpcom.org. It's a marketing/presentation change, not a change of ownership. Right now XPCOM is buried inside the Mozilla browser project and very few people are aware that it can be used as a standalone tool. By giving XPCOM it's own identity it would have more of a chance to grow as a standalone platform. Something like xpcom.mozzila.org could work.
On the ownership issue: I (speaking for mozilla.org) *am* looking for more heavy lifters for XPCOM, to do such things as "fix" the "there can be only one components directory" that Ari has been working in the newsgroup, and the lack of component manager thread safety that bites you and many others. I am more than willing to help, certainly by code advice and review, and I believe jband has shown that he is too. I don't know if you have the time and interest, e.g., to take on the component manager thread safety problem.
So ownership can and should change, but the coordination of owners, peers, and consumers of XPCOM should happen at one site, not two or more, and I hope that mozilla.org can still be that site, whatever domain name(s) are used to reach it.
Perhaps I should formalize a "call for owners". Eric Raymond (in CatB) observes that disownership happens all the time in open source. XPCOM is not disowned (except by turnover among netscape.com employees :-( ) so much as it is "good enough" (according to "worse is better", see
http://www.jwz.org/doc/worse-is-better.html) for most of the paid-by-netscape.com contributors, and everyone has his hands full elsewhere. If new heavy lifters can fix the bugs I mention above, and help take XPCOM to the kind of indepent component (system library) status, while not breaking Mozilla too badly (negotiate changes, and deprecate then obsolete in major version milestone steps), we all win.
Sorry to digress, I'm taking advantage of your post to work some material of my own. More in a separate post.
94r0kp$[EMAIL PROTECTED]">In fact, [EMAIL PROTECTED] has unified the two on the autoconf-based platforms, IIRC. If there isn't a bug on file for complete unification, please file one and cc: cls, jband, and me -- or tell me to do it. Thanks.Another issue: why is there a browser build of XPCOM and a standalone build of XPCOM? Couldn't there be just a single XPCOM? NSPR has a single version. There are only six XPCOM C files using XPCOM_STANDALONE. The differences look to be fairly small.
94r0kp$[EMAIL PROTECTED]">I suspect that it's too late because of different API and semantic commitments, and that the NIH and license phobia I mentioned earlier are still problems, but I'm cc'ing wtc in case he wants to reach out.Has anyone from the NSPR group talked to the Apache APR group? Is there any hope of avoiding two portable runtime efforts? Apache has split APR off into a standalone project for 2.0.
/be
