Module-system requirements, draft 2

[Tim Boudreau]

On Wed, Apr 1, 2015 at 11:58 AM, <mark.reinhold at oracle.com> wrote:

> 2015/3/31 6:57 -0700, tim_ellison at uk.ibm.com:
> > Last few comments:
> >
> > (a) Just to ensure this is not misinterpreted, perhaps consider
> rephrasing
> >
> > |  - _Protection domains_ --- At run time it must be possible to
> associate
> > |    the code in modules with protection domains, for the purpose of
> > |    granting security permissions.
> >
> > as
> >
> >   - _Protection domains_ --- At run time it must be possible to associate
> >     modules with protection domains, for the purpose of granting security
> >     permissions to code in those modules.
>
> The existing wording is intentional, to allow for an approach (as we
> discussed) that's based on associating class loaders with protection
> domains rather than mandate an extension of the protection-domain
> concept to associate specific modules with protection domains.  The
> former approach is simpler and may be adequate, but the latter is
> not ruled out.
>
> > (b)
> > |  - _Non-prescriptive version strings_ --- Version strings must have a
> > |    precisely-defined syntax and be totally ordered, but otherwise their
> > |    format should be as general as possible in order to accommodate
> > |    existing popular version-string schemes.
> >
> >
> > I'm trying to reconcile the requirement for version strings to be
> > "non-prescriptive" and have a "precisely-defined syntax".  The need
> > for a defined syntax is not reflected elsewhere, so is it sufficient
> > that they are simply totally ordered, and otherwise left to the needs
> > of the configuration management systems that assemble coherent sets of
> > modules?
>
> Yes -- that's exactly what this requirement is trying to capture.
> To define a total order requires a precise syntax, but otherwise the
> specification shouldn't force a specific interpretation of version
> strings.
>

I wonder if "total order" is actually too strong a statement.

I think in the extremely long run, arbitrary version numbers invented by
fallible humans may become attractive, while commit-hashes from SCMs such
as git or hg have a number of desirable attributes:
 - The exact state of the source tree is recoverable from a hash
 - Assuming the compilation environment includes enough metadata to
reconstruct it, this can act as a very-expensive-to-compute HMAC - you can
determine if the bits you received are an exact match for the bits you
build (modulo a bunch of things that could break that)

I can imagine a versioning scheme which used partial order -

Instead of 1.0,  bae62770d3ba
Instead of 1.1, bae62770d3ba / d452b222d78
Instead of 1.2, bae62770d3ba / d452b222d78 / 3c4a81666a4
Instead of 1.3, bae62770d3ba / d452b222d78 / 3c4a81666a4 / 3ec0e3bb788cb
Instead of 1.4, d452b222d78 / 3c4a81666a4 / 3ec0e3bb788cb / 79792b0779

such that determining if 1.3 is newer than 1.1 is still a fast test (scan
left to the first common known ancestor hash), but in fact, given two
disjoint version strings, total order cannot be determined (some threshold
number of parent hashes are required so as to make this a non-problem
unless you don't upgrade libraries for a decade, but which can be solved by
acquiring an intermediate version that overlaps the other two, or acquiring
all known versions and topologically sorting them).

I realize that's a bit hypothetical, but we have today the ability to
generate far more reliable (if less intuitive) version strings than
arbitrary dewey-decimal.  So the point I'm trying to make is that you don't
actually need total order to answer this-comes-after-that questions, so
perhaps we don't want to insist on it.

-Tim