Currently, ExportProviders in hale support only a single target in form of a LocatableOutputSupplier. The Locatable interface supports only a single URI as a location. This doesn't cover use cases where an ExportProvider needs to write to multiple targets, e.g. when partitioning GML output into multiple files.
Another problem is that it might not be known beforehand how many targets will be written or what their URIs will be. Therefore, there also needs to be a way to let other components, like InstanceValidators, know which targets were actually written.
During the implementation of #331 the concept of a MultiLocationOutputSupplier was introduced that allows the StreamGmlWriter to put file URIs for all GML parts which are then used (in the GUI) by the validation process to validate all written files. This, however, does not work in the CLI because there the validators are set up before the output is written.
Even if a means for an InstanceValidator instance to retrieve what targets were written from the ExportProvider will be implemented (e.g. by using a delegate that lazily evaluates the target property of the ExportProvider), the validator would then need to be able to handle multiple input files. However, similar to the ExportProviders supporting only a single target, InputProviders support only a single source.
A question to be discussed is, whether it would be better to depart from the single source/target paradigm (and if so, how) or to find workarounds for multi-source/multi-target scenarios in the existing framework.
This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in two weeks if no further activity occurs. Thank you for your contributions.
Currently,
ExportProvider
s in hale support only a single target in form of aLocatableOutputSupplier
. TheLocatable
interface supports only a singleURI
as a location. This doesn't cover use cases where anExportProvider
needs to write to multiple targets, e.g. when partitioning GML output into multiple files.Another problem is that it might not be known beforehand how many targets will be written or what their URIs will be. Therefore, there also needs to be a way to let other components, like
InstanceValidator
s, know which targets were actually written.During the implementation of #331 the concept of a
MultiLocationOutputSupplier
was introduced that allows theStreamGmlWriter
to put file URIs for all GML parts which are then used (in the GUI) by the validation process to validate all written files. This, however, does not work in the CLI because there the validators are set up before the output is written.Even if a means for an
InstanceValidator
instance to retrieve what targets were written from theExportProvider
will be implemented (e.g. by using a delegate that lazily evaluates thetarget
property of theExportProvider
), the validator would then need to be able to handle multiple input files. However, similar to theExportProvider
s supporting only a single target,InputProvider
s support only a single source.A question to be discussed is, whether it would be better to depart from the single source/target paradigm (and if so, how) or to find workarounds for multi-source/multi-target scenarios in the existing framework.