Ari Heitner wrote:
> 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 agree that it's kind of both a curse and a blessing. For example, I
use Window Maker as my window manager here, which supports a wide
variety of formats for its icons. But to do so, it needs to link against
a number of libraries providing the support for these (PNG, GIF, TIFF,
XPM, etc). In a sense, it is dependent on those, but at the same time,
it isn't. If I do not have the GIF component, then I can function
perfectly fine without it, I just won't be able to use GIF images as
icons.
So we actually do not want to be *dependent* on these components/modules
(like we would be if we linked against those libraries). So this is
cool.
But on the other hand, you might have an application which ABSOLUTELY
REQUIRES some components to be present, and at the moment there isn't a
standard way to make sure the application doesn't try to run without
them.
By the way, did you ever try to run WINWORD.EXE on Windows, without
using its installation program, just copying the binary to your system
(provided you don't have and never had Word)? It actually *runs*, but
I'm not sure you can even save files, or type anything. But it doesn't
crash (last I checked, it was a while ago, might be Word 97).
And remember that in a component world, late bindings are what you are
after. This implies more runtime checking, that's the price to pay. If
there is a component that is utterly critical to your application, then
right in the main(), just after initializing XPCOM, check whether the
component you need is registered and complain if it isn't!
> COM is *wrong* as a system architecture.
I'm not sure this is a correct affirmation. Maybe "Microsoft COM" or
"Microsoft's implementation of COM" is wrong. Maybe that the
free-for-all that is going on in Windows machines is to blame. Come on,
applications that comes with their own copies of system DLLs? What the
heck is that? When I see the same stuff happening on Linux, I complain
loudly.
> 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.
Even if there was a consistent ABI for C++ objects, COM has its place,
to enable binding at the last possible moment, which is a good feature
to have.
> The illustration of *why* COM is wrong is Windows :)
You're having a case of the bozo-bit anti-pattern here. :-)
(The bozo-bit is a bit that we set in the informations we keep in our
brain about a person. When that bit is set for someone, every time that
person says something, it goes to the bit-bucket almost directly. This
is Bad. You're supposed to evaluate all of their inept ideas separately,
so that the day they stumble on a great idea, you're there to pick it
up.)
> 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 :)
Windows handling of DLLs sucks dead rodents through a garden hose,
nobody will disagree with that.
Does COM (or the COM ideas at least) have anything to do with that? I
don't think so.
The way I see this, a system-wide XPCOM would have a (not too large)
number of areas to put DLLs in. One of them might be /usr/lib/xpcom.
Only root can install stuff there, just like only root can install stuff
in /usr/lib. Configuration for that component should be somewhere like
in /etc, as usual. Users shouldn't be able to modify that.
Users should be able to put DLLs in ~/lib/xpcom or ~/.xpcom/lib or
whatever, and have the associated configuration in ~/.xpcom or in other
dotfiles, as usual.
I think application could optionally have an area specific to them, but
I am not sure this is a good idea.
One thing I am not sure about also is the search order of these
component repositories.
XPCOM currently depends a bit too much on its registry (component.reg).
It should be resilient to destruction of that file. The way I see this,
this should be the equivalent of /etc/ld.so.cache. Instead of having
only one global such file, it might be stored in the same directory as
the DLLs. It's content should preferably be validated, but ld.so doesn't
validate its content, and we don't have problems that often (and they're
easily fixed by running ldconfig as root).
It would be nice if the autoregistration could be a bit more
progressive, for example doing a stat on the directory, and if it is the
same mtime that is stored in the registry file for that directory, don't
bother checking every file. If you do bother checking every file, don't
bother with those with the same mtime as the last time you checked. If
the file doesn't exist, then autoregister everything, possibly only in
memory (if you do not have write access to that directory).
I think Mozilla already do something almost like this, but it could be
improved, at least to the point of not requiring write access to the
directory.
Note that ability to unload DLLs is very important if you end up doing
autoregistration often like that (if the file is missing or incomplete).
> 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.
That's a good point, even for just Mozilla-the-browser.
--
"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence." -- Edsger W. Dijkstra
