Skip to Content.

edugain-discuss - Re: [eduGAIN-discuss] [eduGAIN-SG] eduGAIN metadata feeds

edugain-discuss AT lists.geant.org

Subject: An open discussion list for topics related to the eduGAIN interfederation service.

List archive


Re: [eduGAIN-discuss] [eduGAIN-SG] eduGAIN metadata feeds


Chronological Thread 
  • From: Leif Johansson <leifj AT sunet.se>
  • To: Ian Young <ian AT iay.org.uk>
  • Cc: "edugain-discuss AT lists.geant.org" <edugain-discuss AT lists.geant.org>
  • Subject: Re: [eduGAIN-discuss] [eduGAIN-SG] eduGAIN metadata feeds
  • Date: Wed, 27 Nov 2019 12:04:58 +0100



Skickat från min iPhone

27 nov. 2019 kl. 11:50 skrev Ian Young <ian AT iay.org.uk>:



On 2019-11-27, at 09:35, Leif Johansson <leifj AT sunet.se> wrote:

It is certainly possible to argue that any reasonable scheme is "the
right one"... or that none is.

Lacking a specification, that's true. I think in this case the prior choice was based on "earlier participant wins" for stability.

Whatever the "right" answer is in principle, though, the right answer during a tooling upgrade is "whatever the previous system did".

This involved a major version bump of pyFF which (cf semantic versioning) means both semantics and APIs can and do change. It is still possible to achieve the same effect with 1.X simply by reversing the load order.



Having said that I believe it would be better for edugain to spend
some time to describe a more precise way to express the desired
outcome when an entity appears in multiple feeds and then we can
get that implemented instead of relying on the current method which
is pretty brittle and depends on a side-effect on how pyFF handles
parallelism.

A formal (or at least semi-formal) spec of the desired behaviour would indeed be desirable. We might then find that we wanted to change the behaviour. I don't think we should change the behaviour absent such spec work, though.

    -- Ian






Archive powered by MHonArc 2.6.19.

Top of Page