<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:08 PM, Cantor, Scott

      wrote:<br>

    </div>

    <blockquote cite="mid:75751128-D00F-4F0F-938B-9F4134E154AF@osu.edu"

      type="cite">

      <pre wrap="">On 12/9/15, 6:20 PM, "dev on behalf of Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfofputmanb@georgetown.edu"><dev-bounces@shibboleth.net on behalf of putmanb@georgetown.edu></a> wrote:

</pre>

      <blockquote type="cite">

        <pre wrap="">I don't know that I've ever consciously intended to do this, but I don't necessarily object.  But gets into the whole OpenSAML api vs. impl question.

</pre>

      </blockquote>

      <pre wrap="">

What question specifically? I haven't intended to be crafting any mixed messages about how we're going to treat those modules.

</pre>

    </blockquote>

    <br>

    I just meant that:  We've discussed that we probably can't

    effectively maintain the -api vs -impl distinction in OpenSAML, as

    currently defined in the versioning policy, without building a lot a

    registries/factories/etc to serve as a bridge.  If we: 1) chose not

    to do that (it would be a lot of work which isn't funded), and 2)

    don't find another way (a middle ground) to reconcile version policy

    with the codebase (i.e. tweak definitions) then 3) the other

    (extreme) alternative would be to dispense in OpenSAML with the

    notion of -api vs -impl entirely.<br>

    <br>

    In the latter case there's no point in moving anything because

    everything would be API (or we consolidate all of them to functional

    modules - security, saml, etc - but thereby don't need to take into

    account where specific classes need to go).<br>

    <br>

    As I've mentioned, the other notion behind -api/-impl was Chad

    wanting to plan for possible OSGi usage.  That didn't necessarily

    have the same api/impl requirements as the current versioning

    policy. But that's likely moot at this point.  I doubt for example

    that we're going to re-do (again) the IdP architecture, based on

    OSGi.<br>

  </body>

</html>