reconciling the Reloading Attributes with the Dynamic Attributes

[Cantor, Scott]

> 1) What is the effect of the metadata's @cacheDuration attribute on the
> operation of a reloading provider (such as the
> FileBackedHTTPMetadataProvider)?

It sets bounds on the refresh timer's behavior, I believe, so it can trigger earlier refresh attempts if it's small, within the bounds of the min/max settings. It's a signal to try for new data more often, which seems logical to me.

> 2) What is the effect of the metadata's @validUntil attribute on the
> operation of a dynamic provider (such as the HTTPMetadataProvider)?

The dynamic provider has a bit of "duality" with how it treats validity. In the dynamic layer, it actually applies both cacheDuration and validUntil at the same time to compute upper bounds on what it calls "validity", which isn't really what you think of as metadata being valid or not, it's just refresh behavior since the whole idea is that the original source should be able to supply the latest metadata anyway. So either attribute can reduce the refresh delay and cause it to query more often.

But at the top layer, it's still looking only at validUntil to decide on validity, as it should.

> The answer to the first question would appear to be "none" since a
> FileBackedHTTPMetadataProvider is a non-caching metadata provider. Is this
> correct?.

I don't think so.

> The answer to the second question depends on the value of the
> requireValidMetadata attribute but why then is the
> expirationWarningThreshold attribute confined to the reloading attributes?

It does not depend on that and I don't know anything about the other attribute, so I can't say.

-- Scott