(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.
> 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.
> ) 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?
> 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 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?
> 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
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.
>
>
>
> cheers,
>
> ari
>
/be
