Clarify save_result #289
Clarify save_result #289
Conversation
save_result.json
Outdated
| "summary": "Save processed data to storage", | ||
| "description": "Saves processed data to the server-side user workspace of the authenticated user. This process aims to be compatible with GDAL/OGR formats and options. STAC-compatible metadata should be stored with the processed data.\n\nCalling this process may be rejected by back-ends in the context of secondary web services.", | ||
| "summary": "Save processed data", | ||
| "description": "Makes the processed data available in the given file format to the corresponding medium that is relevant for the context this processes is applied in:\n\n* For **batch jobs** the data is stored in the server-side user workspace of the authenticated user. STAC-compatible metadata are usually made available with the processed data.\n* For **synchronous processing** the data is directly sent to the client.\n* For secondary web services the behavior depends on the service type. Usually, the data is directly provided to the secondary web service, but calling this process may also be rejected by some service types.", |
There was a problem hiding this comment.
For batch jobs the data is stored in the server-side user workspace of the authenticated user.
I might be missing something, but the concept "workspace" is only/mainly used for the file storage part of the API.
Batch job results are not necessarily stored in a way that's compatible with that file storage API (e.g. in VITO backend, the batch result are not stored in a user specific "home" folder or something like that)
There was a problem hiding this comment.
For synchronous processing the data is directly sent to the client
minor note: the "directly" might be misleading because of additional zipping of the result.
There was a problem hiding this comment.
For secondary web services the behavior depends on the service type. Usually, the data is directly provided to the secondary web service, but calling this process may also be rejected by some service types
I'm left confused about this
- "directly provided": does that mean "skipping save_result"?
- sentence starts with "usually .. directly provided ...", but what is the "otherwise" part? non-directly providing like a batch jobs?
- what if service type requires save_result, but it is missing?
I guess it's not worth trying to explain all the secondary service aspects here? Maybe the description should be very high short and just refer to some general secondary services docs (e.g at https://openeo.org/documentation/1.0/developers/api/reference.html#tag/Secondary-Services)
There was a problem hiding this comment.
-
batch jobs / user workspace: Yes, it's not necessarily the same. We are also removing that language in load_result: Load by URL and filter by extents and bands #292, so this can be aligned. Simply removed it.
-
synchronous: Changed to
For synchronous processing the data is sent to the client as a direct response to the request
-
sec. web services: Hmm, is this better?
Secondary web services are provided with the processed data so that it can make use of it (e.g., visualize it). Web service may require the data in a certain format. Please refer to the documentation of the individual service types for details.
There was a problem hiding this comment.
yes looks good.
re: secondary services: I guess we don't have enough experience with that at the moment to have fully polished docs, so I'm fine with last proposal
fixes #288