On Fri, Jan 26, 2001 at 05:33:20PM -0500, Braden McDaniel wrote:
> In article <20010126154708.A1044@andrew>, "Ari Heitner"
> <[EMAIL PROTECTED]> wrote:
>
> >
> > While the version info *is* there in DLL's, it's not sufficient.
>
> [snip - a lot of stuff I agree with]
>
> Having the version in the name works just dandy for things that are
> linked with (and as has been mentioned, tracking dependencies for such
> libraries is one of the nice features libtool provides). But how useful
> is this decoration for shared objects that don't get linked with at
> compile time--i.e., XPCOM modules? It obviously isn't something that
> would be tracked with linking tools. Seems to me that runtime is the only
> time you can resolve the version on these things. Furthermore, wouldn't
> multiple versions of the same XPCOM module be a Bad Idea given the way
> XPCOM currently works? (I know some potential solutions to this problem
> have been discussed, but IIRC they weren't at all simple to implement and
> there was no clear winning strategy.)
>
I agree. It's a major issue.
I would almost argue that it's worth restricting yourself:
- 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.
- obviously if your application ships with a pile of libraries, it's
reasonable to assume they'll be installed in the way the application
specifies.
For that matter, it wouldn't be at all unreasonable, as
COM/CORBA/whathaveyou grows on Unix for some formal specification of "I
depend on this UUID" to grow, so that dependencies are apparent to the
packaging system. Having the dependency be runtime may be necessary, but
*no* program should ever be installed without all its depencendies met ...
that's a "civilized system" issue.
[crystal ball time. this is Linus' *old* crystal ball, he's got a newer and
presumably more accurate model now].
I see XPCOM growing into the general COM system for Unix -- there's just not
that much more left to get it there. CORBA is firmly implanted (due to GNOME
and others) but CORBA is slow enough that nobody will complain (from the
CORBA side) about an XPCOM<->CORBA bridge (more likely actually an
XPCOM<->Bonobo bridge), which may well get finished in the next little while
(the bridge wouldn't be any slower than talking to CORBA objects running on
another ORB).
This means that *now* is the time to think ahead a bit. While ordinarily I
totally agree with the "write it bad now, fix it later" philosphy, this is a
case where we *know* the pittfalls. This isn't the first time COM is being
implemented as a system architecture -- it's the second. And the errors of
the first attempt are pretty glaring :). But with a little care we can get
things far more right this time (i hope).
As Jaron Lanier (VR guru) says, technologists have an almost holy
responsibility: when we sanctify and enshrine technologies as standards or
norms of one kind or another, we can set the whole course of advancement for
decades. We've gotta be real careful when one of those opportunities comes
up.
[/crystal ball. maybe i'm attaching way too much importance to this?]
ari
