Brendan Eich wrote:
> >> The idea is that an imperfect (but okay) component system that get used
> >> widely and pervasively is infinitely better than even a perfect one that
> >> nobody uses.
>
> Agreed. How many times must I cite Richard P. Gabriel's "Worse is Better"?
At least fourty-two times, for sure! :-)
> >> XPLC thrives toward simplicity and efficiency, so that
> >> there are NO EXCUSES for someone not to make some component (in the
> >> largest sense, like a DLL library) an XPLC component.
>
> Ok, but how many other projects are using XPLC? /me goes to read your
> advogato post.
None. XPLC has just started to materialize in code, but since it's been
2 years that I'm thinking about this, making prototypes, scribbling
notes, examining other similar systems (like XPCOM), implementation is
not the biggest part.
As mentioned in some of ESR's writing, I'm getting to something usable
before releasing it to the whole world.
I have a number of test apps around, including a real one (Quadra, a
game I used to work on).
> >> This is directly related to the relatively low level of community
> >> reuse of mozilla.org's code.
>
> Mozilla code turns up in lots of places. I'd like to see "relatively
> low level" quantified and compared to other open source projects of
> similar relative youthfulness.
GNOME isn't much older, and some of the GNOME projects are on an amazing
number of machines and used visibly by a number of other projects. But I
agree with you mostly and ...
> I'm skeptical. I'll tangle with braden in a separate post.
... I expect you to do just that. :-)
> >> Developers right now have to jump
> >> through some serious hoops if they want to leverage mozilla.org
> >> libraries. JavaScript isn't too difficult, but it's still harder
> >> than it should be.
>
> Yes, it is (I speak with some authority on JS), but it's not harder than
> many, many other open source projects. The Mozilla JS engines are used
> by dozens of small to large companies, by my count.
Well, I know that it's not *that* hard, but I feel it might be harder
than many other open source projects. It took me an hour to add PNG
support to my Quadra game using libpng, having *never* worked with it
before. *That* is good.
I am not discounting your work, but you have your priorities and goals,
and I have mine. I know you'd prefer it if I was contributing to XPCOM
instead, but hey, hire me and I'll lend you a hand with a smile. :-)
In the meantime, I do what I find fun to do, even if it is doomed
because my project is not coming from a high-profile organization like
Mozilla.org. I try to "help" in a way by coming here and contributing
cycles of my brain to you guys. I'd love to do more, but I only have so
much time, like everyone else...
Note that I don't even use Mozilla, when I come here and contribute code
or
> For some reason, I'm still doing a lot of work on JS, but I can't do
> everything. Rather than throw small stones, could you and braden help?
> Or did I or norris, or others involved with the Mozilla JS engines, do
> something to scare away contributors?
Until today, nothing had scared me away from Mozilla actually, funny you
mention that. I'm in the middle of getting roasted on #mozilla right now
(ask Akkana if you want detail), including by a Netscape employee. Lotsa
fun.
I do not mean to throw stones of any size to anyone. If I had infinite
time, I'd be either fixing XPCOM to my complete taste, or finishing XPLC
and converting the whole of Mozilla over to it (as a kind of XPCOMv2),
but obviously, I do not have infinite time.
I thought about fixing XPCOM, and deemed it as too difficult, mainly
because of the pressures you have/had on getting a browser out the door
at Netscape. Not counting more or less technical opposition about things
like not supporting exceptions so that they can't do the transparent
remoting that Mozilla doesn't really need.
My goal with XPLC is very clear. I want it to be so damn easy to use and
simple that it becomes the stdio of componentry. Maybe stdio sucks arse
and can't do network I/O out-of-the-box, but it's *there* and it's
probably the most used I/O library in the world. Just about nobody
thinks before using stdio, it's so damn easy that they just DO.
Now, there are compromise needed to achieve that, and I'm not sure
Mozilla.org is prepared to take them (though I think that if XPLC
couldn't at least theoretically replace XPCOM in Mozilla, it would be a
failure).
When I find a good idea in XPCOM, I pick it up for XPLC. I just wanted
to "sort-of" contribute back good ideas I picked up elsewhere or that I
had myself. I'm not dreaming: I know nobody will implement this just for
the heck. But if I have one good idea that turns out to help Mozilla a
great deal, I'd be a freakin' idiot not to tell you. Listening is not so
expensive. It'll let you see about the "doing" part.
For example, the service manager interface I am very proud of. The way
it stands now, I can do just about everything the compoent manager *and*
the service manager (eh, I don't even know if these two both still
exist!) with a single, super-simple interface. *Everything*.
I picked that idea up from the component loader of XPCOM, if I remember
correctly, and just applied it somewhere else I found it even better.
:-)
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/xplc/include/xplc/IServiceManager.h?rev=1.7&content-type=text/x-cvsweb-markup&cvsroot=xplc
> >> As for NSPR, XPCOM, and Necko... Well, the
> >> initial investment required is high enough that many developers
> >> will simply dismiss these potential solutions.
>
> I cry foul. NSPR is much more mature, documented, and widely used than
> XPCOM and Necko. You chose to highlight braden's wrong-headed (but not
> all wrong, half-truths are like that) claims, so I'm asking you to
> justify them, too. I'm ready to rumble with braden, in a followup to
> his post.
Ok, I drop NSPR and even Necko. I'm just thinking about XPCOM here,
that's my line of "business".
As a simple example, the test that exercise dynamic loading and
interface switching (includes a dynamic module) for XPLC is 5310 bytes
of code, with many asserts in the way (almost every other line of code
is an assert!). Apart from the assert macros, no macros have been used,
the code is ultra-clean and easy to understand.
But it will almost probably *never* become remotable. But check this
out:
http://www.sun.com/research/techrep/1994/abstract-29.html
And so on... (I can rant and rave about components all night if you want
me to...)
--
"And the Answer is... 42." -- Deep Thought
