Extending the SP Dynamic Metadata Provider

[Tom Scavo]

On Wed, Oct 25, 2017 at 5:04 AM, Rod Widdowson <rdw at steadingsoftware.com> wrote:
>
> 1)      More Intuitive configuration of MDQ setup.
>
>  This will be the most common setup and to simplify it I’d propose a similar extension to the IdP:
>
>         <MetadataQueryProtocol>http://mdq.example.org/global/</MetadataQueryProtocol>

I agree with Scott, this could be more straightforward. When I first
encountered the above config, I was confused since I had thought the
order of child elements mattered. Anyway, how about something like
this:

<MetadataProvider type="mdq" baseurl="http://mdq.example.org/global/" />

> 2)      More intuitive configuration of Directory based dynamic lookup.
>
> This would be to align it better with the IdP's LocalDynamicMetadataProvider (and there would be significate changes under the hood)
>
> My suggestion would be to add new attribute "sourceDirectoryPath", yielding something like this:
>
>         <MetadataProvider type="Dynamic" sourceDirectoryPath="/opt/sp/DynamicMetadata/" />
>
> This would allow us to deprecate (but not disallow) file:// URLs.

This feature is intriguing but I still don't understand the use case.
How do files end up in this directory and what is the file naming
convention?

> 3)      Specify a backing cache directory for (HTTP)
>
> The idea is that after a reboot the SP would be able to lookup the local directory rather than reach out to the MDQ server.  This is
> similar to the reload from backing store thing that the Batch providers do and would speed up restart.

This is great. I was thinking about this just the other day.

> This would be similar to the
> configuring an IdP DynamicHTTPMetadataProvider with a persistentCacheManagerDirectory.

I guess I'm missing something since I wasn't aware the IdP had this
feature. Hmm.

> My suggestion would be to add new attribute "cacheDirectoryPath", yielding something like
>
>         <MetadataProvider type="Dynamic" cacheDirectoryPath="mdqCache" >

What file naming convention will be used in the cache dir?

> As far as configuration goes, that’s all I can see by way of low hanging fruit.  Have I missed something?  Or have I got something
> wrong?

What about discovery? What's your discovery strategy in the face of
per-entity metadata? Seems like that should come first.

Just my two cents.

Tom