Drop "public" UDP feature?

[soxofaan]

This is a question that came up while working on a supporting refactor for Open-EO/openeo-aggregator#125. I was slowed down quite a bit with this non-standard "public" UDP feature:

• user johndoe saves a UDP with public=True
• other users can list this UDP under GET /processes/u:johndoe
• other users can load this UDP with namespace u:johndoe

also described in python client docs at https://open-eo.github.io/openeo-python-client/cookbook/udp_sharing.html

I think we nowadays settled on UDP sharing through URLs (e.g. with the official remote process definition extension) instead of this non-standard "public" flag.

Is it still useful/necessary to keep this non-standard "public" UDP feature alive?
Or can we clean that up to simplify the related code paths?

[soxofaan]

on CDSE I still see related requests happen, for example :

• GET /openeo/processes/u:3e24....500e576574/BIOPAR
• GET /openeo/1.2/processes/u:3e....e576574/biopar_8bands_060325_v2

[soxofaan]

I added warning log on usage of these non-standard urls to better track this

[jdries]

The EOPlaza docs and samples point towards this:
https://docs.terrascope.be/Developers/EOplaza/Services.html#develop-an-openeo-algorithm

So that requires a proper update and retraining the trainers on the preferential way to publish UDP.

[soxofaan]

@Pratichhya also mentioned that this feature is still in use can not just be dropped yet.

[soxofaan]

But also to consider here is this related, more general problem:

• UDP support in a federation context? openeo-aggregator#176

We're planning to push users more towards federated openEO backends, but in that context we at most have hacky/partial support for UDPs (in the /process_graphs endpoint sense) even for the standardized part of that subsystem.

[Pratichhya]

Ahh thank you @soxofaan will be following it.
@jdries thank you for pointing that out, will update the documention on limiting the use of 'public' flag