Skip to Content.
Sympa Menu

metadata-support - Re: [Metadata-Support] Re: optimizing metadata refresh

Subject: InCommon metadata support

List archive

Re: [Metadata-Support] Re: optimizing metadata refresh


Chronological Thread 
  • From: Tom Scavo <>
  • To: Ian Young <>
  • Cc: "" <>, Tom Scavo <>
  • Subject: Re: [Metadata-Support] Re: optimizing metadata refresh
  • Date: Tue, 24 Mar 2015 16:47:52 -0400

On Tue, Mar 24, 2015 at 11:55 AM, Ian Young
<>
wrote:
>
> [snip]
>
> There are some other wrinkles (e.g.: how do you compare one Set<DOM things>
> with another? how do you arrange to advance validUntil while not having
> that cause premature re-rendering?)

Yes, I think those are the more interesting questions. Basically, is
it worth the hassle on the server to save the client from having to
refresh metadata more often than it really has to? I don't know.

>> I understand the per-entity metadata server will refresh it sources
>> regularly and often, but why should that force a refresh at the
>> client? Can and will we use HTTP Conditional GET to eliminate (what
>> seems like) unnecessary metadata refreshes?
>
> Conditional GET is a slightly different consideration. That's actually
> fairly simple to implement within the MetadataService because it can be
> defined in terms of differences in a strong validator derived from the
> *rendered* results (which already exists). The tricky part is to go over
> and above that and avoid re-rendering when the *appropriate parts* of the
> source data have not changed (even though the aggregates have), because
> re-rendering will almost always end up with different results in practice
> because of things like validUntil moving forwards.
>
> Phew. I'm guessing you may have some follow-on questions...

It might be easier to discuss this on one or more of our biweekly
calls and then summarize our thinking in a document (like you did with
the TLS question). What do you think?

Do you think there might be some protocol bits lurking here? It was
wise of you to separate out the SAML portion of the protocol since we
might be able to use that to profile what weak and strong validators
on SAML metadata might look like.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page