search

Open-EO / openeo-api

The openEO API specification
http://api.openeo.org
Apache License 2.0
91 stars 11 forks source link

Avoid "UDP" terminology #540

Closed soxofaan closed 4 days ago

soxofaan commented 1 week ago

While starting on follow-up work for #515 and the just merged #538, it occurred to me that this new "remote UDP extension" uses the term "UDP" (user defined process), which has a couple of problems:

I know we merged #538 like an hour ago, but is there still room to reconsider usage of "UDP"? Some quick ideas:

m-mohr commented 4 days ago

Maybe we should actually define UDP in the API spec and add a clarification for UDP vs. UDF.

UDP stands for "user-defined" which makes sense in the context of an authenticated openEO session,

I don't agree. Users can define processes without an (authenticated) session. UDP just describes the concept of an openEO process that is not pre-defined by the spec and has a process graph included. So the term UDP is correct in this context.

We could rename the extension, the other proposed alternatives also don't seem very intuitive to me though. The Extension is a bit ambiguous in that people could understand execution, so we should add something to clarify (definition, retrieval, ...). Maybe "Remote Process Definition Extension"?

soxofaan commented 4 days ago

UDP stands for "user-defined" which makes sense in the context of an authenticated openEO session,

I don't agree. Users can define processes without an (authenticated) session.

My focus here was not on the "authenticated" or the "session", but just on the "user" as persona in the openEO system (you can indeed be a user without having a session). My concern is mainly that the user defining the process and the user executing the process can be different. In the original definition of "user-defined processes" both the defining and executing users are the same (because the spec isolates UDPs per user by design), so there is no confusion. But now we start talking about situations where some user "Alice" can refer to a process defined by another user "Bob" or even some kind of external organization or algorithm provider. In this context, the term "user" (for the entity that defined the process) loses its original meaning. And even more extreme, the feature would even allow executing a pre-defined process from another backend or directly from the official spec (if the process definition includes a "process_graph" field), so it also does not make sense to express things in terms of user-defined versus pre-defined.

That's why I propose to get rid of "user-defined" from the extentions's official name and make it generic and more future-proof.

Maybe "Remote Process Definition Extension"?

That's exactly what I proposed above too :smile:

m-mohr commented 4 days ago

Don't judge me, I have a cold 🙈

Anyway, fixed by https://github.com/Open-EO/openeo-api/commit/777fa7c3f55b0f2e36aa7b0be3ca4fa18662f74d

soxofaan commented 3 days ago

:+1: get well soon