You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since @lukpueh is back :)) and together with @jku are working on a repository design, I'd like to resurrect an old issue #589.
How does, according to you, the new code should treat delegations of the type
A -> C
B -> C
given that A and B may delegate different paths, use different thresholds etc.
Does it make sense for practical use cases? Should we simplify our life and just forbid it? Should we support it?
We've just merged #1528 which means that the client will skip C in this example, the second time it reaches it through B (if the pathpattern is matched in both).
My naive thinking is that for the client 1528 is fine: in a specific target path lookup we don't want to traverse into C again if we've already visited it (results should be same), but generally speaking there's no harm in allowing C from being accessible through multiple routes: A different target path lookup might only go "targets->B->C" and I don't see why we'd want to prevent that just because A also happens to delegate something unrelated to C.
The repository application might want to enforce simple graphs for the simplicity, but that sounds like an application decision.
Description of issue or feature request:
Add tests dedicated to forming complex delegation graphs:
Explore formats for describing delegations (idea: Graphviz dot format)
The text was updated successfully, but these errors were encountered: