Extending the SP Dynamic Metadata Provider

[Rod Widdowson]

> > 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?

It's based on this: https://wiki.shibboleth.net/confluence/x/hYGNAQ  Also in the current SO you can do it.


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

SHA1 of the entityId - like the SP.

> What about discovery? What's your discovery strategy in the face of
> per-entity metadata? 

Same as it always has been: "And then a miracle occurs".   People either care deeply about discovery and invent new wonder ways of doing it or they don't care at all (or they don't see why you wouldn't use Twitter/FaceBook/Skype).  In the time I've been associated with the project there has been a seesaw from one to another.  We are currently mid-way between apathy and "It will be wonderful, just do this".

Further, discovery has nothing to do with SP operation. The discovery protocol frames the DS as an oracle. So, to encumber an SP with gigabytes of memory usage just to support it seems needless.  If you need it you have the static providers if you don’t, don’t use them.

The SP currently feeds the EDS because it is convenient.  There is no reason why an MDQ couldn’t, provide the EDS stream (IIRC there is already an endpoint to stream out all entities, it just needs to be persuaded to spit out JSON).   

I suspect that someone will come up with an Ajax proposal before very long - for those who are blessed with a reliable, secure network with zero latency and infinite bandwidth.

Even if you needed the SP to generate the JSON it could be persuaded to stream the metadata it and drop the memory.

R