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

[Leif Johansson <leifj AT sunet.se>]

Skickat från min iPhone

> 27 nov. 2019 kl. 11:55 skrev Tomasz Wolniewicz <twoln AT umk.pl>:
> 
> Hi Leif,
> 
> W dniu 27.11.2019 o 10:35, Leif Johansson pisze:
>> 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.
> 
> The current solution is of course something that has always been a
> questionable choice but it has one big advantage, the algorithm does not
> depend on per-entity history. If we were to go, what I would consider a
> more natural way, that is server the entity from the federation that
> published it first, we would need to remember it and consult it during
> aggregation. We would also need to decide what happens if an entity
> drops out from the supplying feed and what happens if it returns, will
> the algorithm depend on the length of this break etc.



> 
> We did spend a considerable amount of time considering various dark
> corners, things were discussed in the early days of eduGAIN when the
> current aggregator was being built. No one was really pushing the
> problem and we decided that relying on the current ordering approach is
> giving reasonably predictable results and is easy to implement so this
> is what was done.
> 
> You now seem to be saying that the aggregation result done with pyFF may
> be unpredictible, this might mean that the incoming feeds would already
> need to be stripped down so that no clashes may acrually appear. That
> would mean that a considerable amount of side programming would be
> needed. I think that the only way forward is do discuss what you might
> want to implement in pyFF and what should be adjusted to make eduGAIN
> work up to everybody's expectations.
> 

To be clear: pyFF has never made any claim or promise that the URIs in a load 
is processed in a particular order but that doesn’t mean the order is 
unpredictable or random, in fact the order is stable - it has simply changed 
during a major release.

I am also not at all sure about your analysis about what the right way to 
“pick a winner” is nor why in fact it matters where an entity was registered 
first. This is a different issue however - requires a separate discussion.

Cheers Leif

> Cheers
> 
> Tomasz
> 
> 
> -- 
> Tomasz Wolniewicz    
>          twoln AT umk.pl        http://www.home.umk.pl/~twoln
> 
> Uniwersyteckie Centrum Informatyczne   Information&Communication Technology 
> Centre
> Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
> pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
> tel: +48-56-611-2750                            tel kom.: +48-693-032-576
> 
>