New changes to our data model allow for a ca.mcgill.a11y.image.route parameter, which is defined in this comment and allows for clients to select a subset of preprocessors and handlers relevant to a task. This is primarily intended for use with follow-up queries.
For each request, the route parameter must be used if present and assumed to be default if not. Invalid requests will be rejected. For every preprocessor and service, only those with a route label that matches the parameter provided in the request will be run.
E.g., assume the following preprocessors and handlers:
PP_A with a label value of "default,followup"
PP_B with a label value of "followup"
PP_C with no label set.
H_A with no label set.
H_B with a label value of "default,followup"
If a request is received with no route value or a route of "default", PP_A, PP_C, H_A and H_B would run.
If another request is received with a route value of "followup", then PP_A, PP_B, and H_B would run.
An activity diagram is included below to help clarify the necessary checks, though note that the process of getting a list of preprocessors or handlers and sending information to them has been collapsed into a single loop. This is not how it would run in the orchestrator, and is done here to avoid unnecessary repetition of the checking logic.
New changes to our data model allow for a
ca.mcgill.a11y.image.route
parameter, which is defined in this comment and allows for clients to select a subset of preprocessors and handlers relevant to a task. This is primarily intended for use with follow-up queries.For each request, the route parameter must be used if present and assumed to be default if not. Invalid requests will be rejected. For every preprocessor and service, only those with a route label that matches the parameter provided in the request will be run.
E.g., assume the following preprocessors and handlers:
If a request is received with no route value or a route of "default", PP_A, PP_C, H_A and H_B would run. If another request is received with a route value of "followup", then PP_A, PP_B, and H_B would run.
An activity diagram is included below to help clarify the necessary checks, though note that the process of getting a list of preprocessors or handlers and sending information to them has been collapsed into a single loop. This is not how it would run in the orchestrator, and is done here to avoid unnecessary repetition of the checking logic.