[note: i'm going to wander way the hell off topic of this particular
subthread rather than reply to 6 different messages in the big thread ...]
On Wed, Jan 24, 2001 at 07:06:31PM -0500, Braden McDaniel wrote:
> In article <20010116105404.A745@andrew>, "Ari Heitner"
> <[EMAIL PROTECTED]> wrote:
>
> > *yes*: don't sweat it. forcing implementers to freeze interfaces once
> > the
> > magic ship-date has arrived, and then to support both old interfaces and
> > any new ones added later ... is one of the worst lies perpetrated by
> > Booch/Grady/Gamma/etc...
>
> The "lie" is the insistence on thinking in terms of "versions" of the
> same product line, where in fact a new product line is appropriate.
>
> > Multiple simultaneously installed versions (i.e. major version numbers
> > on shared libraries) are key :)
>
> Such schemes simply disguise a lack of imagination for a new product name
> when one outgrows the feature set of the current solution.
>
I completely disagree. This is not the issue at all :) Version changes or
renaming, doesn't matter, as long as it's consistent :)
The issue is that COM in general encourages applications not to have *any*
real specification of "i depend on this functionality which lives in this
library with this major version number (or if it's a braindamaged library,
this library with this specific complete version number". The result is
massive dependency problems and applications that just don't work.
I think it's a *huge* danger (and that's why i didn't dignify it with a
reply) when Waleri (and others) suggested that XPCOM should provide a
systemwide COM implementation for UNIX.
COM is *wrong* as a system architecture.
COM represents the fact that many systems *don't* have a consistent ABI for
C++ objects, and that they don't have a sane library control system.
The illustration of *why* COM is wrong is Windows :)
a) We *can't* have lots of user-level applications running around
registering components at a system level. This is a *major* breakage in
Windows (as working components are inadvertently replaced by broken ones
needed by other programs). The fact that UNIX *doesn't* allow programs
running as user to do this kind of thing is *right*. COM has *fundamental*
violations of UNIX philosphy which *should* not be overlooked -- package
installation at the system level *must* occur as root; but when programs run
they should *not* modify their system-wide state. Following this rule will
keep an installation from rotting -- witness Debian, which you install once
and upgrade and run cleanly forever. And COM is a *major* reason for the
*major* breakage of the Windows platform -- the whole "Invalid DLL" error
syndrome, and the end result of playing "farmer in the DLL" with a system
that's been running too long (i.e. Windows suffers *major* OS rot). This is
*not* the UNIX way, and COM does *not* solve any UNIX problems. It's a
*mistake* (caveat: i'm a unix bigot. windows will solve its problems when it
realizes it's a badly-implemented unix :)
b) the above does *not* mean that programs can't use COM as an internal
architecture -- as Mozilla does. And it doesn't mean that COM can't be a way
to do object introspection and RPC -- CORBA is quite successfully used to
exactly those ends by GNOME. But they get *only* what they need from CORBA,
and don't use it where it isn't appropriate (it's a buttload slower :) so
they're less inclined to that sin).
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.
But I totally agree that xpcom *should* become a separate component (in the
sense of "separate leadership, separate cvs tree") from mozilla sometime
aroiund 1.0, by which time XPCOM should be *very* well set.
...
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).
However i *refuse* to blame Netscape for wanting to get this browser out the
door. They *do* have their priorities. If anyone has the momentum to
disagree with that, they're welcome to fork the project. I think that's a
laughable thing to say right now tho :). New features will *always* get
short shrift before a major release -- witness the flamewars over getting
ReiserFS into 2.4.
...
The stuff I want is *not* a major disruption of XPCOM's nature -- I don't
want to turn it into a systemwide component manager (before doing that,
you'd need to do a real careful study of what MSCOM has that XPCOM lacks;
but as I mentioned unsubtlely above I think that's a dumb idea :).
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.
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.
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? :)
cheers,
ari
