seeding the DynamicHTTPMetadataProvider

[Tom Scavo]

On Wed, Sep 28, 2016 at 1:43 PM, Brent Putman <putmanb at georgetown.edu> wrote:
>
> On 9/28/16 10:24 AM, Tom Scavo wrote:
>>
>> All of those entities need to be in the file cache upon
>> startup.
>
> Hmm, it's really the other way around.  The "priming entityIDs" we're
> discussing don't *need* to be in the persistent cache.  If they're not,
> they're be resolved as usual via an HTTP fetch.
>
> If they *are* however, then the "priming" of any given entity is really a
> no-op, since there is nothing further to resolve.  I was going to bring that
> up vis-a-vis the cost of the priming component block the startup if done
> synchronously.  Assuming the priming entityIDs are the ones actually being
> regularly used in the resolver, then it's likely that many (or most, or all)
> of those would be in the persistent cache, and so become no-ops. So the
> priming op itself may not actually be all that expensive, and synchronous
> wouldn't really be an issue.  The expense is instead paid earlier, by the
> resolver initialization from the persistent cache.

Yes, that makes sense. Thanks Brent.

Tom