
<html>

  <head>

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

      http-equiv="Content-Type">

  </head>

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

    <br>

    <div class="moz-cite-prefix">On 11/12/14 1:45 PM, Brent Putman

      wrote:<br>

    </div>

    <blockquote cite="mid:5463AAB2.8020301@georgetown.edu" type="cite">

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

        http-equiv="Content-Type">

      <br>

      <br>

      <br>

      I imagine it may be too late to change every place where we

      instantiate a PRC to use a (new) 2-arg constructor - and that's

      assuming the message context instances are even available at that

      point.  But you guys are more familiar.  If it's just changing a

      few places, etc, then maybe worth doing.  <br>

    </blockquote>

    <br>

    Actually, just realized, the MC are not necessarily typically

    available, I think, in our current model.  The inbound is generated

    by the Decoder usually, after the PRC is ctor-ed.  My memory is

    hazy... I think this is accounted for by a difference in processing

    models.  I think I originally designed: 1) decode, so get an inbound

    MC 2) create your InOutOperationContext  with that (and a new

    outbound MC), as context for the middle "business logic" processing

    3) run "business logic"  4) encode outbound.<br>

    <br>

    So I think the actual design with the PRC (which Chad added in the

    IdP, and was later moved to OpenSAML) diverged there. Now there's an

    impedance mismatch (I think) - we assume you create a PRC upfront,

    and then hang stuff off of it as you go.<br>

    <br>

    Have to think more - maybe there's a way to solve - like just

    overriding and making the setParent(BaseContext) public on

    MessageContext.  Then wherever we set the MC's on the PRC, just also

    set the parent explicitly.  <br>

    <br>

    Unless this isn't a big deal, in which case we can just leave as-is

    for now.<br>

    <br>

  </body>

</html>