In article <20010127203640.C422@andrew>, "Ari Heitner"
<[EMAIL PROTECTED]> wrote:
> 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.
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)?
> - 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.
As long as the UUID refers to an interface and not an implementation, I
agree. (But I think you really mean for it to refer to an implementation.)
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
products with a long release cycle. Most open source projects don't fit
that model, and for good reasons. But what are those reasons? Marketing
and bugspotting, mostly. You call for discipline on the part of the
clients, but I think more discipline on the part of module providers is
required.
The solutions you propose here sacrifice an important advantage of the
component system. And why must that sacrifice be made? Simply because the
module authors can't get the versioning story right?
Interfaces *can* be frozen. And it doesn't mean the end of the world when
it happens. Yeah, it's a pain in the ass when an interface must be
obsoleted, but that's the price you pay for binary compatiblity.
Freeze early and freeze often. It's appropriate to freeze XPCOM
interfaces at each milestone release. What's needed is a means of
deprecating interfaces so that they can be removed from the system after
a certain amount of time.
--
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
