-
Notifications
You must be signed in to change notification settings - Fork 31
Description
Another problem is with how parameter resources get resolved now. In the CLI setting, we allowed an ambiguity between JSON literals and file names, so the latter would have to be resolved to absolute paths (for the various resource locations), which in turn obviously dependend on the processor class (because of the custom module
location):
core/src/ocrd/decorators/__init__.py
Lines 95 to 103 in 4d33491
if 'parameter' in kwargs: | |
# Disambiguate parameter file/literal, and resolve file | |
def resolve(name): | |
try: | |
return processor.resolve_resource(name) | |
except ResourceNotFoundError: | |
return None | |
kwargs['parameter'] = parse_json_string_or_file(*kwargs['parameter'], | |
resolve_preset_file=resolve) |
But in the network setting, where parameters can be added to the processing or workflow request, no such resolution (from resource name to resource path) takes place –
- On the server side, there is only a parameter validation step
core/src/ocrd_network/server_utils.py
Line 220 in 4d33491
report = ParameterValidator(ocrd_tool).validate(dict(job_input.parameters)) - On the client side, there is only the JSON string vs file disambiguation, but no prior resolution.
core/src/ocrd_network/cli/client.py
Line 142 in 4d33491
req_params["parameters"] = set_json_key_value_overrides(parse_json_string_or_file(*parameter), *parameter_override)
Did we abandon the entire mechanism, or am I missing something?
Originally posted by @bertsky in #1303 (comment)