A cleaner way to prefetch MDQ metadata?

Wessel, Keith kwessel at illinois.edu
Mon Jun 27 19:05:45 UTC 2022


So, are you saying it's bad to use the method proposed by InCommon to add additional resolvers to support my use case of loading metadata for an embedded discovery service?

I agree that this isn't pre-fetching -- it's just manually fetching. But the end result is basically the same.

Is there another way to accomplish what I'm trying to do other than downloading a huge federation metadata aggregate?


-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Monday, June 27, 2022 2:00 PM
To: Shib Users <users at shibboleth.net>
Cc: Wessel, Keith <kwessel at illinois.edu>
Subject: Re: A cleaner way to prefetch MDQ metadata?

On 6/27/22, 2:44 PM, "users on behalf of Wessel, Keith via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:

>    This seemed obvious enough that I thought I'd ask about it before making a feature request because it
> seems like there must be a reason it's not yet an option.

The way the caching works and the fact that you can script it to perform queries made it pointless to implement anything here. There is no prefetch option, really.

>    In showing a colleague how to set up MDQ prefetches for an SP that's running an embedded discovery
> service using the method documented by InCommon here:

That's not pre-fetching, it's "install a different metadata resolver for specific cases". Obviously you can do that but I have no idea why anybody would.

> This made me wonder if it would be possible to create a metadata filter of type prefetch that could be put on
> the dynamic metadata provider block. Like the include metadata filter, it would just take a list of entity IDs
> and, on SP start-up, it would automatically fetch them. Since they probably need to be kept as persistent
> entities in the SP for embedded discovery purposes, it would also make sense to re-fetch them when they
> expire instead of letting them be removed from the internal cache.

I suppose one could, but I don't really see the point. We're not planning to make any part of the MDQ layer "persistent" beyond the caching we do already, and there is not any way to do discovery with those resolvers. It's simply non-functional in the code. They don't implement that feature, by design.

-- Scott

More information about the users mailing list