SP V3 metadata types

[Cantor, Scott]

On 6/14/18, 3:48 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:

> Actually, I don't recall that you have asked for this (resolver to implement condition GET internally).  That is not what I
> got from OSJ-234 (which is about 1) how we compute the next refresh for the edge case of the source returning null,
> and 2) caching negative lookups).

I saw it as essentially the underlying reason one would return a null in the remote case. In the local case, a null would presumably mean "the file hasn't changed", and in the remote case, the reason you'd know the file hadn't changed would be a 304. But I recall that the code in the two cases wasn't exactly lined up the same so I can't say that I assumed it was easy to do it in one case as the other.

> In fact, IIRC I think we have in the past discussed explicitly the re-processing implications of use of the caching
> HttpClient, and I thought we were fine with it. 

It doesn't bother me as much in the remote case because the refresh checks there are going to be much less frequent, and the overhead of a network call is huge compared to processing time, even a simple/short one.

So, no, it doesn't give me a ton of concern but it doesn't really seem like you get much from the caching client if you have to reprocess the file anyway. All you're saving is the actual data transfer, which for a single metadata instance is nothing. The HEAD alone is the hit, turning that into a GET probably has little impact in practice.

So in a sense, I would say if we *don't* do this, the caching clients are largely moot. The value comes from the resolver knowing it can skip its work, whereas in the batch case the value is also affected by the avoidance of the transfer (though even that's still dwarfed by the signature cost these days).

-- Scott