Config param to choose task distribution logic #124
Labels
priority: high
High priority
type: feature
New feature or request
workload: days
Likely takes days to resolve
Check #119 (comment) for context.
A good solution would keep the middleware handler truly generic. Each middleware should follow one of a number of abstract signatures. At least the following ones should be covered:
tesTask
in,tesTask
out)tesTask
and list of known TES instances in, ranked list of TES instances outThe user would then list a number of middleware functions (either part of proTES or external ones) in the config, for these two (and possibly other, if we can think of any) signatures/sections. The handler would then apply these in the listed order. For example:
Here, the handler would mutate the request by first harmonizing incoming requests, then converting any v1.0.0 requests to v1.1.0 (obviously, these are just examples of what middleware could hypothetically do). The handler would also set the destination by first discarding any TES instances that the user anyway doesn't have access to, then use the built-in distance task distribution logic to find the available/accessible TES that is closest to the input data.
Ideally, the handler would also check that the signature of the provided functions fit.
Other than that, there should be no specific logic in the handler (which there currently is), and no mention of any specific, hard-coded middleware (which there also is).
It might be useful to check if/how abstract classes/interfaces are done in Python to specify and validate the function signatures.
The text was updated successfully, but these errors were encountered: