On 13/05/2013 06:53, Marvin Humphrey wrote:
None of the DSO loading mechanisms presented by various operating systems
provide satisfactory solutions to the kinds of problems Clownfish sets out to
solve, so I think we should be prepared to layer our own mechanism on top.
I actually like the Mach-O approach. It's unfortunate that there isn't a
simple solution for minor version checks on ELF systems.
The first component of our solution should be a Clownfish::Version class, with
the following characteristics:
* Version numbers are fundamentally arrays of integers. They are not
strings. They are not floating point numbers.
+1
* Auxiliary properties of parcels, such as "alpha", "testing", "release
candidate" and so on, must not affect the result of comparing two Version
objects.
IIUC, this would mean that an alpha for "1.0.0" would have to look like
"0.9.9-alpha".
I would also argue that we should support Version objects with an arbitrary
number of integer sub-versions, and that omitted numbers should be treated as
trailing zeroes for the purposes of comparision.
# all the same
2
2.0
2.0.0
2.0.0.0
...
We only have to make sure that such a scheme maps to all host languages
and systems we want to support. For example, Mach-O libraries only
support X.Y.Z versions with a 16-bit X and 8-bit Y and Z.
FWIW, the "Semantic Versioning Specification" (http://semver.org/) seems
to become more and more popular. From what I understand, it's mostly a
codification of the MAJOR.MINOR.PATCHLEVEL approach.
I'd like to propose that major version numbers be considered part of the
parcel identifier and that we use a name mangling scheme to embed them in
exported symbols, while providing macro aliases for programmer convenience.
// For Lucy version 0.x:
#define lucy_Indexer_new
org_apache_lucy_0_Indexer_new
// For Lucy version 1.x:
#define lucy_Indexer_new
org_apache_lucy_1_Indexer_new
Unless I've missed something, I believe that scheme will allow multiple major
versions of a library to coexist within the same process. And since the
user-level symbols are the same, client code can be adapted and recompiled to
use different versions of a library with minimal source code churn.
To make this work, we would have to support multiple class registries
within the same process and VTables couldn't be singletons.
I think the ideal would be to store different DSOs in different directories
derived from the full parcel identifier, including major version number.
$CLOWNFISHLIB/org/apache/lucy/0/lucy.so
$CLOWNFISHLIB/org/apache/lucy/1/lucy.so
However, I'm not sure we need that right away.
This would make it hard to find the libraries at compile and run time.
On UNIX systems, it's no problem to have multiple major versions of a
library in a system directory.
Nick
