Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hide or mark proprietary processes #23

Open
4 tasks
m-mohr opened this issue Oct 28, 2021 · 3 comments
Open
4 tasks

Hide or mark proprietary processes #23

m-mohr opened this issue Oct 28, 2021 · 3 comments

Comments

@m-mohr
Copy link
Member

m-mohr commented Oct 28, 2021

Originates from https://github.com/openEOPlatform/architecture-docs/issues/21:

Some processes are available just at one back-end, but are pretty specific to the back-end or some data or so.
We think these should be hidden or marked explicitly as experimental processes or as being unavailable at some back-ends.

For example, some of these processes that are available at VITO:

  • discard_result - Use case unclear
  • get_geometries – No file storage supported right now
  • load_disk_data – No file storage supported right now, once available replace with load_uploaded_file instead?!
  • sleep – Use case unclear
@soxofaan
Copy link
Member

soxofaan commented Oct 28, 2021

I think this is partial duplicate of (or at least related to)

Initially the aggregator exposed only the intersection of processes across back-ends, but then for pragmatic reasons we decided to work with the union.

@m-mohr
Copy link
Member Author

m-mohr commented Oct 28, 2021

I think the union is still fine, but unrelatedly we may need to either have a black-list or handle some processes in a special way, I think. Long-term we may even switch to a white-list so that only "approved" (tested and aligned) processes are listed...

This issue was meant to focus to handling the specific processes short-term, which is probably somewhat independent of the long-term solution.

@jdries
Copy link
Contributor

jdries commented Oct 28, 2021

seems low priority but we can perhaps do something easy in the documentation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants