Ari Heitner wrote:
> > > The illustration of *why* COM is wrong is Windows :)
> >
> > You're having a case of the bozo-bit anti-pattern here. :-)
>
> I agree :)
>
> You're quite right. I'm throwing out possibly several babies with some
> (undeniably nasty) bathwater.
Microsoft had a few good ideas (out of hiring just about everyone of any
importance, like Clemens Szyperski), but IMHO, horrid execution tainted
by incredibly twisted marketing-driven requirements.
I always find it very funny when they try to deprecate something, but
without actually deprecating it: "yes, Foo is good stuff, don't stop
buying it, but see what amazing feats NewFoo can do!". Result: a lineage
of legacy tracing way back there to the dark ages of microcomputing.
> I mean "COM is always wrong" in the context of "wanting COM for Unix so we
> can make Unix just like Windows, with no consideration of what is
> braindamaged about Windows/MSCOM is always wrong".
YES. Keep thinking, at all time!
There are some good things with Windows, just not enough that I can use
it without risking permanent nerve damages. :-)
In some aspects, Windows 95/98 seems much lighter than a Linux running
GNOME for example. MSIE 5.5 is also much faster than Mozilla (opens up
in about 1 second on a Pentium 166 with 24 megs of RAM), to hit the nail
on the head, and quite modular (IEXPLORE.EXE itself is 60kb).
I'm not bashing Mozilla here, just saying that they must be doing
*something* right, so pissing on everything they do is definitely wrong.
But copying mindlessly is just as wrong!
> And I have *zero* problem with COM on Unix as long as it maintains sane Unix
> paradigms -- things like "only programs running as root can modify
> system-wide settings" and "general libraries are provided by the system;
> applications can specify dependencies, but don't get to mess with the
> available libraries, except in their own out-of-the-way places".
Didn't rayw had something on searchable paths for component modules?
Also, I would like to remind people of something: components are
supposed to be stateless. *Instances* of components can be stateful if
they want, but the components themselves shouldn't be, so that they can
be deployed in various environment (in this case, different UIDs).
Having "resources" (data that is pretty much static) is okay.
When components have state, things go sour for good old Unix sanity...
> As long as XPCOM remembers to learn from the best of the worlds it bridges,
> we'll be in very good shape.
Amen brother. :-)
--
"Bad managers wouldn't be nearly so harmful if they only knew they
were bad." -- Bram Cohen
