[webstack-discuss] Apache and APR-Util Using OpenLDAP [LSARC/2009/123]

[Matt Ingenthron]

Jyri Virkki wrote:
> James Carlson wrote:
>   
>>> To keep some perspective, what Sun calls volatile sand is what all of
>>> these 3rd party applications build their ldap support on and their sky
>>> isn't falling from what I'm told.
>>>       
>> In that case, "Volatile" might not be the right classification after
>> all.
>>     
>
> Perhaps. My sense is that some parts of OpenLDAP APIs are stable (and
> some apps use only those parts) while other parts are unpredictable,
> but that's just hearsay. It's up to the team owning OpenLDAP (whoever
> that is or ends up being) to figure that out.
>   

My apologies if this is obvious to some of you, but the paragraphs above 
don't go with the ARC definitions here, does it?

As David Comay educated me on once before, "volatile" doesn't say 
anything about the code/API stability directly.  It defines the contract 
between the dependencies in OpenSolaris, and therefore says something 
about what the owner will/can do with updates to the package.  From a 
recent doecument 
<http://opensolaris.org/os/community/on/os_dev_process/> (October 2008):

    The following are the (new) relevant Public taxonomy levels:

    Stable: The interface may only change incompatibly in a Major
    release. Interfaces intended for usage by ISVs and system
    integrators require this level of support to be useful to these
    customers.

    Uncommitted: May only change incompatibly in a Major or Minor
    release. This is appropriate for some system management facilities
    and new, untested interfaces.

    Volatile: May change in any release vehicle. This usually only
    useful when the interface definition is controlled by a body other
    than the OpenSolaris community and it is viewed that tracking that
    community is more important than interface compatibility.

    Not an Interface: Just a convenience term to label what may appear
    to a supported interface as not being supported. This is the default
    classification and this term is only explicitly applied when there
    is likely to be confusion.

    The precise terms for the public taxonomy levels is still under
    discussion, as part of the update to the Interface Taxonomy document.

    Note that the ability to make an incompatible change in a given
    release vehicle does not make that a requirement. For example, most
    interfaces controlled by someone other than the OpenSolaris
    community are currently classified as Volatile, but synchronization
    with major incompatibilities introduced by those communities is
    often deferred until a Minor release is available.

It's not clear to me if 
<http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/> 
is updated or not.

A lot of this is moot for the Apache/PHP<->OpenLDAP since the Apache/PHP 
projects (which we aim to integrate without core modification as much as 
possible) already tracks the OpenLDAP project.  I can't speak for other 
components depending on OpenLDAP, but it would seem that trying to 
artificially hold back any component would actually cause more harm than 
good.

The only difficulty comes in if various components depending on OpenLDAP 
diverge.  Since the interface definition says this thing may change at 
any time, doesn't that effectively turn the contract around and say 
"depend on it, but recognize that you'll be responsible for dealing with 
any updates that happen to hit you".  For the vast majority of things in 
OpenSolaris which would depend on it, this is probably okay since the 
upstream projects have demonstrated years of being generally in synch or 
having reasonably stable interfaces between each other.  At least, 
that's my impression since it just works on other platforms.

Prior docs said you shouldn't depend upon things classified as volatile 
at all, but this has been updated for OpenSolaris as I understand it.

Then again, I'm not in engineering.... but I do know that there has to 
be a reasonably simple resolution here.  The functional requirement has 
come up in Sun deployments of PHP.  It's an extremely common use case. 

Again, my apologies if this is obvious to everyone or I'm way off base here.

- Matt