<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

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

    <p><br>

    </p>

    <br>

    <div class="moz-cite-prefix">On 12/20/17 1:07 PM, Cantor, Scott

      wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:656FE592-153A-4772-9DEB-FDE88A014496@osu.edu">

      <pre wrap="">On 12/20/17, 2:03 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="">Although I didn't implement this originally (Chad did),

</pre>

      </blockquote>

      <pre wrap="">

The part I thought you did was the "load initially from backup and then do a refresh", which I had the impression was a recent change we made in response to the performance problems. That seems to be the behavior under discussion as you alluded to later.

</pre>

    </blockquote>

    <br>

    Oh, yes, I did implement that recent performance change.  I didn't

    implement the original provider code, which still had the

    file-backed aspect.  It's not swapped in to my brain, but I think it

    used to only load from the backup file if the HTTP fetch failed?  I

    might have that completely wrong.   But to me that's not

    fundamentally different - I think Tom would say that it shouldn't

    load it period if it's not signed, and that's what I thought we were

    discussing.<br>

    <br>

    And the current behavior has the same practical result as the former

    behavior, just with a few seconds delay: unless there's a fetch or

    validation problem, you're going to ultimately get a freshly fetched

    set of data. And if there is a problem, you wind up with the backup

    data.<br>

  </body>

</html>