reconciling the Reloading Attributes with the Dynamic Attributes

[Tom Scavo]

On Tue, May 8, 2018 at 3:11 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>>
>> Btw, note that the refreshDelayFactor attribute has exactly the same
>> description in both cases. That description really only makes sense for a
>> reloading provider. In the case of a dynamic provider, the description is very
>> confusing.
>
> It's doing the same thing, modifying the caclulated value that governs how often it refreshes

But you said "the dynamic ones don't refresh per se" so I'm confused.
Either the refreshDelayFactor attribute on the dynamic provider is
misnamed or the minCacheDuration/maxCacheDuration attributes are
misnamed. There's a glaring mismatch here.

There's a significant optimization lurking just under the surface
(which is why I'm probing the details). If you deprecate
InlineMetadataProvider (no big loss), you're left with just two groups
of metadata providers: the reloading providers and the dynamic
providers. In that case, a handful of attributes common to both may be
elevated to the Common Attributes.

>> I believe you. The point I'm trying to make is that httpCaching="none"
>> in the case of FileBackedHTTPMetadataProvider is an apparent contradiction.
>
> It isn't, but then I know what the code is doing.

What if all four of the HTTP Caching Attributes were deprecated? Since
caching is covered quite nicely in the HttpClientConfiguration topic,
[1] the HTTP Caching Attributes are merely convenience attributes. In
the vast majority of cases, they probably shouldn't be changed anyway,
so they turn out to be less than convenient, I think.

Tom

[1] https://wiki.shibboleth.net/confluence/x/PgEOAg