
<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <br>

    <br>

    <div class="moz-cite-prefix">On 12/9/15 7:34 PM, Cantor, Scott

      wrote:<br>

    </div>

    <blockquote cite="mid:7D7CB7C4-5B6E-4776-A1ED-1C43E490C774@osu.edu"

      type="cite">

      We have control over both sets of code and we can make adjustments

      unilaterally. Other people can't, so it's for them I think we

      maintain the split.</blockquote>

    <br>

    Probably deserves a whole thread but:<br>

    <br>

    I thought the whole concern here was that external projects

    consuming OpenSAML *must* depend on stuff in the -impl modules,

    since that's where all the good stuff and actual functionality is

    located. (excepting the XMLObject provider stuff which already has

    the registry indirection layer).  But that's notionally an

    unrealistic burden and requirement, because the -impls are unstable

    and can change in breaking ways.  Ergo there's a problem: They have

    to depend on unstable stuff, practically no way to avoid.<br>

    <br>

    If we keep the split, it seems therefore required to modify the

    version policy in some way for OpenSAML (as a library, distinct from

    a standalone project like the IdP). Meaning possibly "impl" in

    OpenSAML is not the same as "impl" in the IdP.  But I don't think we

    know how to do that, or whether it's even possible to do sanely.<br>

    <br>

    So I guess to me that whole ball of wax is "The OpenSAML API vs impl

    Question".   (Which is just a case study in the "Bottomless Hell-Pit

    Of Software Versioning, Dependency and Change Control Management". 

    In bookstores next month, published by Masochist Press.)<br>

  </body>

</html>