Mike Cheponis wrote:
> Two comments here:
> 
> 1) Seems to me a better architecture would be client/server.  The ap requests
> the library from a "library server" - this would return the absolute path
> name of the library.

>Something like library_server(lib_name, lib_version);

*shriek in horror*

> How it finds it can be hidden in an abstraction.  (I think that it's a bit of
> a hack to include the version in the library's filename.)
> 
> The abstraction could be extended to return the actual library bits & load
> it, whether the library was local or remote (over the network).

I don't see why would one like to have something like that.
Useless bloat.

> 2) "DLL Hell" must be avoided; in the Windows world, conflicting or "upgrade"
> DLLs sometimes render older apps inoperative, since the newer DLLs sometimes
> aren't bug-for-bug compatible.

The problem on M$ windows (note that "windows" is Xerox TM AFAIK)
is that there are occasions when the DLL
has same name and other functionality; related problem is that
applications on windows tend to install their own system libraries.
If you install older app, you may well break some newer one, which
uses newer version of the system library.

It's avoided by Unix's major and minor version numbering - when
the functionality changes, the major is raised and old app doesn't
use this new library. If just the interface is enhanced (i.e. new
functions are added), the minor number is raised; old binaries use
new library and even new binaries linked against new library work
with the old library, if they don't use the new functionality.
If just some bugs are fixed, the version number is not changed at all,
as the interface has not changed either (with exception with Linux,
which has even patch level in their library names).

DLL hell is not an issue on Unix, AFAIK. I'm tempted to start bashing
MS for a lousy scheme they came up, but I won't.

Note: it's not very common you WANT to be bug-for-bug compatible --
normally you want to have the bugs fixed ....
Anyway, the issue here is very different from M$ windows world - if there
is bug in library you'd want to avoid, you can go and fix the
library for you, which is not possible on M$ windows. You don't
need to work-around that.

> I think the only general solution for this is to use the exact library with
> a given ap.  Perhaps some kind of "SCCS" for library files could be used,
> so that a binary diff could be applied to a current library file to make
> available previous versions.

Not needed. major.minor is just enough.

Jaromir
-- 
Jaromir Dolecek <dolecek@ics.muni.cz>      http://www.ics.muni.cz/~dolecek/
"The only way how to get rid temptation is to yield to it." -- Oscar Wilde