export_to_workspace

[m-mohr]

Proposed Process ID: export_to_workspace

Context

For the new workspace API we want a way to have a process that explicitly allows to store a result in a dedicated workspace instead of in "the normal user space"

We thought about having it as part of save_result, but then you either mix the storage location with the file formats or you get a number of parameters that depend on each other in save_result, both not ideal.

Backends may not do the intermediate step to store in the normal user space and directly store in the workspace although both processes are present.

The process usually only makes sense in batch jobs, I think.

NOTE: This process may have implications on save_result!

Summary

Exports a result to a registered workspace

Description

...

Parameters

data (or so?)

One issue is that save_result returns a boolean, so we need to look into that. Maybe it should return something else that we can feed into export_to_workspace as data? Maybe a list of files? Or just a generic "result" subtype?

name

Name of the registered workspace.

Type: string
Subtype: workspace-name

Optional: no

folder (or prefix?)

Stores the batch job with the given prefix / to the given folder in the workspace.

Default to null, which uses a unique identifier as prefix (e.g. batch job id).
An empty string stores them in the "root folder".

Q: Should the process by default override files or not?

Type: string or null

Optional: yes, default: null

Return Value

boolean?

Categories (optional)

• export

Links to additional resources (optional)

• Link to workspace API

Details about exceptions mentioned in the description (optional)

• FileExists

[m-mohr]

cc @Open-EO/team-eodc @christophreimer

[jdries]

Should we have most of the discussion in this issue: Open-EO/openeo-api#376
Because there we already collected a lot of thoughts and requirements. I'm also not really clear yet on what the new workspace API looks like.

[m-mohr]

User-generated Collections and user workspaces are not necessarily the same, so they deserve separate issues, I think.
I tried to collect relevant issues and links in https://github.com/openEOPlatform/architecture-docs/issues/215#issuecomment-1748497731 (not being the lead here though, just started with it an hour ago)