On Mon, 29 Jan 2001, Ari Heitner wrote:
> On Sun, Jan 28, 2001 at 03:53:28AM -0500, Braden McDaniel wrote:
> > In article <20010127203640.C422@andrew>, "Ari Heitner"
> > <[EMAIL PROTECTED]> wrote:
> >
> > > - if you depend on a component, *know* which library that component
> > > lives
> > > in. Play games if you have to (bogus symbols or something) to *make
> > > sure* that your executable shows linker-level dependency on that
> > > library. this is just a matter of keeping dependencies transparent.
> >
> > Um, yuck, I think. One of the main problems COM solves (or at least
> > attempts to solve) is that of binary interoperability. Are you asserting
> > that that problem should not be solved (or that it should not be solved
> > the way COM does it)?
>
> What is the "binary interoperability" problem?
Binaries that must be linked with cannot be arbitrarily replaced without
relinking.
> I just don't see the
> conceptual restriction of "I depend on this functionality, which lives in
> this library".
It's the "which lives in this library" part that's the problem. My binary
isn't supposed to have to know where its dependencies live--that's the job
of the registry.
> Anyone can implement a hardware libGL.so or a distributed
> rendering one or whatever -- but it always contains the same symbols, and
> always has the same library name.
>
> I see the COM point of hacking around compiler-specific name mangling -- but
> why not then provide in-library extern "C" factory functions, and use
> COM-style specified-vtable-format interface-only objects? You *still* know
> that IFoo lives in libFoo.so etc etc.
Because that wouldn't break locational transparency for the
implementation.
The problem with "compiler-specific name mangling" is just the problem
that most platforms don't have a standard ABI for C++. The fact that most
platforms *do* have a standard ABI for C is what lets COM get around the
problem, but it's certainly not a problem that you need COM to solve. It's
*just* 'extern "C"'.
> I simply don't see the advantage of divorcing a compile-time-specified
> link. Maybe i'm missing something here?
Locational transparency is an absolute requirement for component
architectures that work across the wire (CORBA, DCOM), but for something
like COM it really only means that you can drop in a new module and (as
long as your interfaces are still working per the original spec) have the
binaries that depend on it continue to work without having to replace them
as well. So it currently means about the same thing for XPCOM; but if
XPCOM has any across-the-wire aspirations, it needs to consider the big
picture here.
> > I don't have quite the animosity toward the notion of frozen interfaces
> > that you seem to have. The system does seem to have been designed for
>
> It's not an animosity -- I just argue for simultaniety. There should be a
> stable interface-frozen current version, and a development version (which
> many people may choose to run). The stable version has (nearly) frozen
> interfaces (i say nearly because occaisionally backporting stuff from the
> new version makes sense; the example here is the kernel) and the devel
> version has zero guarantee of interface stability.
>
> I think such a model is a miserable form of existence :)
>
> It's also the only thing I've seen work.
I don't think a concept of "nearly frozen interfaces" is useful to
(XP)COM. It's either in flux or it ain't. And if it's in flux, don't dare
release any software that uses it. If it's frozen, it sure as hell better
stay that way.
--
Braden McDaniel It is hard to know if nothing is /
http://endoframe.com actually nothing
e-mail: [EMAIL PROTECTED] And thus difficult to know if a policy /
Jabber: [EMAIL PROTECTED] of doing nothing is successful
-- Radiohead
