FOSS and Interface Taxonomy levels

James Carlson James.D.Carlson at sun.com
Wed Mar 5 13:31:01 PST 2008


John Plocher writes:
> Think of
>      "/usr/local-apache1webstack/",
>      "/usr/local-apache22webstack" and
>      "/usr/local-appserverwebstack"...

The funny thing about that proposal is that it does *not* necessarily
map too well into the usual meaning of "Volatile."

Instead, the majority of the internal components used to build each of
those deliveries are likely to be Consolidation Private: they're used
within the build process of that "webstack" and nobody else really
cares what they are or how they work.

The externally visible parts can easily be termed Committed.  If
you're going to nail down different versions and never change them,
then they're as stable as anything is ever likely to get.

The only "Volatile" part might be the base installation directory --
though we could nail that down if we cared to as well.  That's very
likely a hassle for users, but I guess if you're installing and
managing multiple versions of the same software, then you've given up
on that issue.

That's not what we've been discussing here, because we've been
discussing individual contributions to /usr/{bin,lib}.  Volatile for
regular interfaces is a different beast.  It says that
"/usr/bin/foobar" (for example) is:

  - Documented in some fashion, because it's a public interface.

  - Subject to change in incompatible ways at any point in time,
    without notice, perhaps even in a patch.  It might even get
    removed.

  - Extremely ill-advised for any sort of software to build atop,
    unless you just don't care whether your software stops working
    tomorrow morning.

If we're talking about a library or something that's likely used
inside of a script, then that's just a nuisance, not a feature.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677



More information about the opensolaris-arc mailing list