Performing conditional gets with the metadata aggregator

[Ian Young]

> On 21 Mar 2017, at 13:58, Wessel, Keith <kwessel at illinois.edu> wrote:
> 
> Sadly, yes, we’re just running the cli every five minutes to produce a hybrid document from the different sources. If there’s a better approach to produce the same end result, but with caching to enable conditional gets, I’m not opposed.

It does seem as if you can't use the existing cacheing mechanisms in that case. As I say, it looks to me as if the file-backed cacheing client caches the body of the document in the filesystem but relies on an in-memory store for the metadata. Without externalising the metadata, there's nothing to do a conditional GET with.

Tom's suggestion might be the easiest way forward, in that you can easily adapt to calling his script and then the code you have just now with minimal changes (pick up the InCommon metadata from a file rather than directly).

The alternative would be some kind of long-running process in a Java web container handling the aggregation process on a regular basis. My mdq-server would be one such option:

	https://github.com/iay/mdq-server

That's designed more as a web service than for this kind of thing, but you could abuse some of the components there to do what you want. Discarding the web service parts and just doing everything with ItemCollectionLibrary would probably be sufficient as a quick hack. If you have someone who can do basic Spring Boot style apps, you could make it a lot simpler than that, though.

    -- Ian


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170321/7c5cf0af/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3563 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20170321/7c5cf0af/attachment.p7s>