Qs after reviewing Java dynamic metadata resolvers

[Cantor, Scott]

On 9/1/16, 8:55 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:

> That's basically what I had in my mind to do.   The code to save and load metadata to/from
> a file is not complicated.

It's not, but synchronization is always subtle and I was looking for the best way to keep it factored out and not have to clutter all the core code with all that logic, which is something that I don't like about the C++ version of all this.

> Well, as far as providing a totally file-based dynamic resolver (the folder o' metadata
> idea), my plan was for a relatively trivial concrete subclass of 
> AbstractDynamicMetadataResolver.  Note that this class is where all of the "dynamic" bits
> live.  That was deliberate, making it easy to create new dynamic resolvers that are not
> tied to HTTP.  The AbstractDynamicHTTPMetadataResolver  just has the HTTP transport bits
> only.

It's the need to keep deepening the class hierarchies of the resolvers that bothered me a bit.

Also, I was thinking about the work involved for the deployer in having to chain things, and the overlap of having multiple resolvers managing a backing store in each one for essentially the same data. It just seemed a little ugly.

> You may remember that early on in v3 Chad had proposed something that sounds very much
> like that - a 2-part metadata resolver that separated the "source" of the metadata from
> the "resolving" from it.  And in the end we rejected it because there was something
> about it that didn't work.  I'd have to go look at my email archive to swap in exactly
> what it was, but I think in fact it was you who originally pointed out the problem(s). 
> Maybe that's not the same thing as you are proposing here, though.

It's possible I'm overlooking something, but I think that in part the issue there was the amount of development work it would take to get what we *had* to support that, and also that I think this idea works a lot less well for batch resolvers than this one. I think it fits quite naturally here, just like SOAP stacks are technically transport agnostic. When there's already a resolve() method involved, all we're talking about is whether that's an interface itself, or a hook for subclassing.

I suppose in the end it's cosmetic, particularly if the Spring parsing would have to accomodate these different options whether it's a new plugin to the resolver or a new resolver type.

> If your reasoning is that you want to factor
> out the file processing code so it can be reused for the separate use cases of the
> backup files *and* the true file-based dynamic resolver - I think we could achieve the
> same thing via either support classes, or even some sort of file load/save interface+impl
> component that is plugged into both the AbstractDynamicMetadataResolver for the backing
> file use, and the concrete file-based dynamic resolver.

Yes, I am wanting to share that code.

-- Scott