Per-Entity Metadata Working Group

[Nick Roy <>]

If we design the service to be highly available, I don't think we need to 
worry about on-disk cache, which as Scott has mentioned is at the expense of 
the ability of other non-Shibboleth clients to support the same assumed 
requirement.  I think we should focus on a highly available per-entity 
metadata delivery architecture with the assumption that many clients will 
never have the ability to support the on-disk caching.

That said, if others want to run their own local copy, why don't they just 
stand up local HTTP proxies?  This isn't that difficult for them, but I think 
that part of the equation is out of scope for this group.

Nick

On 7/27/16, 1:33 PM, 
"
 on behalf of Cantor, Scott" 
<
 on behalf of 
>
 wrote:

    On 7/27/16, 3:20 PM, 
"
 on behalf of Tom Scavo" 
<
 on behalf of 
>
 wrote:
    
    > What's the difference? I'm talking about HTTP 304, not HTTP 404.
    
    Well, one is an error, one is not.
    
    > You are absolutely correct but I claim a two-week outage of the
    > aggregates served from md.incommon.org has probability zero.
    
    And I claim a two week outage of an MDQ service is pretty much also 
probability zero. Still not getting it. I really just missed the point of the 
example.
    
    > From where I sit, aggregate distribution and per-entity distribution
    > are like apples and oranges.
    
    I do understand that one can tolerate outages that are an order of 
magnitude larger, but in terms of fundamental requirements, they're both 
potentially a highly redundant web presence serving static documents. That's 
apples and some other more expensive kind of apples to me.
    
    But I seem to be in the minority on this, so maybe we could focus this 
discussion on your original subject line. What exactly do people need us to 
implement? At minimum, on-disk cache, clearly.
    
    -- Scott