per-entity - Re: [Per-Entity] implementing a cache on the client
Subject: Per-Entity Metadata Working Group
List archive
- From: Thomas Lenggenhager <>
- Cc: "" <>
- Subject: Re: [Per-Entity] implementing a cache on the client
- Date: Fri, 5 Aug 2016 15:43:00 +0200
- Organization: SWITCH
I agree with Scott C. I would not expect many campuses to install a local MDQ server. But we need to be able to provide a reasonable option for the few ones that want to have an MDQ server under their own control.
I'd compare it with the discovery service. To my knowledge, only a single campus in SWITCHaai installed and maintains a local central DS to be independent from the federation operated one.
Very few SPs use the local Shib Embedded-DS, most rely on the central DS based on SWITCHwayf operated by SWITCH.
No question, the central MDQ of the federation needs to be as reliable as possible. My point was that using some third party file sync service could reduce the complexity to install and run a local MDQ for the few campuses that want to run their own locally.
Monitoring the freshness of the signed files automatically updated by the file sync service would be simple to integrate into a local monitoring environment: E.g. warn if the oldest file in the synced directory is older than one day.
Thomas
On 04.08.16 15:53, Cantor, Scott wrote:
Open this directory structure for access via rsync, Dropbox, OwnCloud,
'you name it' to sync the signed files to campuses operating their own
local MDQ server to get independent from the centrally operated MDQ. No
need for HTTP proxies, just for local MDQ servers at the campuses.
Right, but how many campuses will want to do that? How many will bother? How
many will ignore the whole issue because they're being told that moving to
this new approach suddenly requires extra work from them?
The group consenus was that while nothing we do should or will make that
approach difficult for people to implement, we shouldn't focus on it as a
workaround for delivering a reliable service.
All that said, the Dropbox idea is a good one. Why not piggyback on existing
cloud services? I like it.
-- Scott
--
SWITCH
------
Thomas Lenggenhager
P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 1505 direct +41 44 268 1541
https://www.switch.ch
- RE: [Per-Entity] implementing a cache on the client, (continued)
- RE: [Per-Entity] implementing a cache on the client, Cantor, Scott, 08/04/2016
- Re: [Per-Entity] implementing a cache on the client, David Walker, 08/04/2016
- Re: [Per-Entity] implementing a cache on the client, Nick Roy, 08/04/2016
- Re: [Per-Entity] implementing a cache on the client, Tom Mitchell, 08/05/2016
- Re: [Per-Entity] implementing a cache on the client, Cantor, Scott, 08/05/2016
- Re: [Per-Entity] implementing a cache on the client, Tom Mitchell, 08/05/2016
- RE: [Per-Entity] implementing a cache on the client, Cantor, Scott, 08/05/2016
- Re: [Per-Entity] implementing a cache on the client, Patrick Radtke, 08/08/2016
- Re: [Per-Entity] implementing a cache on the client, Nick Roy, 08/08/2016
- Re: [Per-Entity] implementing a cache on the client, Patrick Radtke, 08/08/2016
- RE: [Per-Entity] implementing a cache on the client, Cantor, Scott, 08/04/2016
- Re: [Per-Entity] implementing a cache on the client, David Walker, 08/05/2016
- Re: [Per-Entity] implementing a cache on the client, Cantor, Scott, 08/05/2016
- Re: [Per-Entity] implementing a cache on the client, David Walker, 08/05/2016
- Re: [Per-Entity] implementing a cache on the client, Domingues, Michael D, 08/05/2016
- Re: [Per-Entity] implementing a cache on the client, Domingues, Michael D, 08/05/2016
- Re: [Per-Entity] implementing a cache on the client, Tom Scavo, 08/05/2016
- Re: [Per-Entity] implementing a cache on the client, David Walker, 08/05/2016
- Re: [Per-Entity] implementing a cache on the client, Cantor, Scott, 08/05/2016
Archive powered by MHonArc 2.6.19.