On Fri, Jan 26, 2001 at 01:11:18PM -0800, Brendan Eich wrote:
> (Hey, are you playing good-cop/bad-cop? I'm catching up on the earlier
> thread, and I really like this cop, or attitude you cop, or whatever:)
>
> > c) John Bandhauer is *absolutely* right. XPCOM is *not* designed to be that
> > systemwide component, and it would need a *lot* of work to get there.
> >
> > I don't think XPCOM can be divorced from Mozilla right now. I totally grok
> > that there are deep COM changes going thru, and that even if there was an
> > xpcom.org website, since the source *must* remain (for now) part of the
> > Mozilla tree, effectively it's got to ride along with the mozilla project.
>
> XPCOM should move to join NSPR and JS as independent components --
> independent in the sense that the build system (at least the autoconf
> one) should allow you to pull and build them when you build a browser,
> or a related app -- or you should be able to say "use the system
> library", just as you can (I hope this still works) with libjpeg, etc.
Agreed.
>
> > But I totally agree that xpcom *should* become a separate component (in the
> > sense of "separate leadership, separate cvs tree"
>
> Why separate CVS tree? For "independent components", cvs.mozilla.org is
> fine, and the browser (the "first commercially released Mozilla browser"
> codename "SeaMonkey" has stuck) tree rules on
> http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey don't apply.
> The browser tinderbox either uses a stable version, installed as a
> system library or in a dist if appropriate, or if necessary, the browser
> build goop pulls a CVS tag, e.g., NSPRPUB_CLIENT_BRANCH.
Doesn't need to be on a separate server. I guess it's fine now :) but it
should be under its own management -- the main thing is that if XPCOM is
going to be usable outside mozilla, the mozilla hackers need to coordinate
any change requests to XPCOM the same as everyone else. Afaik this is the
situation now :) so it's not a big deal.
One thing: i would argue for separate XPCOM versioning -- that way, if XPCOM
people want to implement new features that break mozilla, they can branch
the CVS, and port mozilla to the new version when things settle down.
>
> > ) from mozilla sometime
> > aroiund 1.0, by which time XPCOM should be *very* well set.
>
> Yes. If we go by NSPR's major version theory, every 1.0, 1.1, 1.2
> release can change existing API/ABIs, and minor ones (1.1.1, etc.)
> cannot. I think I have that right. Should we follow suit?
I would argue for 1.0/1.2/even numbers as stable, and 1.1/1.3/odd numbers as
unstable. This has proven very effective for just about every major oss
project.
>
> > completely aside from that, I feel what John is saying about lack of
> > developer commitment. I would *much* rather he spend his time changing the
> > DOM to use XPConnect, rather than implement the new XPCOM features I've been
> > begging him for since December. However, I think thare *are* people who will
> > get this stuff done -- I'm one of them. It'll take guidance from the owners
> > of this stuff (all the code I want to muck with was written by John). But
> > any opportunity to get more people hacking this stuff is a Good Thing(tm).
>
> Hey, this is great. Why didn't I read this post first? Or did you get
> pissed after writing this?
I am hoping i can get some effective retraction of my extremely-out-of-line
comments in people's brains, even if i can't in real life. What can i say, i
don't know what i was on at that particular moment.
Needless to say, i've been a very very very bad disciple. i should be sent
to bed without dessert.
>
> > I just want embedding apps to be able to register their own components and
> > typelibs without access to the mozilla components/ directory (which is
> > considered a "system-level" directory on UNIX). For the time being obviously
> > I can hack around this by just putting in my own private Mozilla
> > installation. And I can scoot around component registration by just
> > reregistering components on startup. The only thing I'd immediately like is
> > support for typelibs in multiple locations.
>
> Is there a bug on file yet?
Getting to it :) not till sunday tho.
>
> > As I've said before, i think mozilla is weak (on the unix side, which really
> > means that all other platforms are broken in allowing mozilla to get away
> > with this) in appropriate support for the userlevel/systemlevel distinction
> > in things like file locations -- reflected in the fact that a user can't
> > even install skins w/o rights to the system mozilla folder. I think that
> > should be the first focus for fixes in XPCOM -- since it's most immediately
> > what mozilla embedders/application developers/whatever need to use XPCOM in
> > their own applications.
>
> I think there is a bug on this -- anyone know the number?
>
> > Taking over the world with XPCOM can wait :)
> >
> > One other comment: I see John jumping in a lot and with a lot of valuable
> > commentary. But I *don't* see scott collins, the ostensible XPCOM module
> > owner, weighing in on any of this stuff. John has his own baby, XPConnect.
> > Where's the XPCOM leadership on this stuff? :)
>
> Good question. See ScottCollins.net, where I first learned that scc had
> broken one hand and sprained another. But XPCOM is too big and diffuse
ah, i remember this. he should get a grad student to take dictation for him
-- RMS did this way way back at MIT, when his rsi prevented him from typing.
actually it was apparently a very amusing episode ...
> for anyone currently or recently involved to own. In fact, I believe
> scc is working on splitting the string classes out into their own
> library, that has no dependencies other than on standard C++. We should
> think about splitting out other stuff that's not "core component
> system", provided we can avoid cycles, and so long as we don't make too
> many teeny libraries.
i agree 100%.
ari "going out of touch for 24 hours now but extremly enjoying this thread"
heitner
