run_udf: "locally stored UDF"?

[soxofaan]

from

openeo-processes/run_udf.json

Line 4 in 75059c6

"description": "Runs an UDF in one of the supported runtime environments.\n\nThe process can either:\n\n1. load and run a locally stored UDF from a file in the workspace of the authenticated user. The path to the UDF file must be relative to the root directory of the user's workspace.\n2. fetch and run a remotely stored and published UDF by absolute URI, for example from [openEO Hub](https://hub.openeo.org)).\n3. run the source code specified inline as string.\n\nThe loaded UDF can be executed in several processes such as ``aggregate_spatial()``, ``apply()``, ``apply_dimension()`` and ``reduce_dimension()``. In this case an array is passed instead of a raster data cube. The user must ensure that the data is properly passed as an array so that the UDF can make sense of it.",

:

The process can either:

   1. load and run a locally stored UDF from a file in the workspace of the authenticated user. The path to the UDF file must be relative to the root directory of the user's workspace.

The use of "locally" and "workspace" is quite confusing here I think. This read like the user can work with a UDF file locally on their laptop/computer, and just send the (relative) path, which makes no sense

"workspace" is also quite ambiguous in this context: it could also be interpreted as the "work environment" the user is working in (e.g. local laptop or a remotely hosted jupyter notebook).

I think we have to find a more precise name for "workspace" to avoid ambiguity in these kind of docs. e.g.: "backend workspace"?

[m-mohr]

Ouch, I meant to make a PR, but accidentally pushed to the wrong branch.

@soxofaan Could you please verify that commit 3f3460e works better for you?

[soxofaan]

yes, the explicit "server-side user workspace" leaves no room for ambiguity