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

Emporio integration #79

Open
wants to merge 28 commits into
base: master
Choose a base branch
from
Open

Conversation

relu91
Copy link
Member

@relu91 relu91 commented Jul 14, 2022

Hi all! this PR integrates emporio with editor. Emporio is meant to be a repository for well-known Thing models. This integration connects the editor with the service giving the ability to select one model from a list as shown in the image below.
image

We are also planning to add a "save to emporio" feature so that people contribute to the list of TMs. Let us know what do you think about this feature and this integration!

CC @ivanzy @sebastiankb

@sebastiankb
Copy link
Contributor

sebastiankb commented Jul 15, 2022

@relu91 many thanks for this PR. Is there also an option to select different directories?

@ivanzy
Copy link

ivanzy commented Jul 15, 2022

@sebastiankb Yes, in fact there is a form that allows users to change the default URL of the Thing Model Repository -- as the figure illustrates.

image

@relu91
Copy link
Member Author

relu91 commented Jul 15, 2022

yes, sorry I posted an old picture in the PR description. 😅

@thjaeckle
Copy link

Do I understand correctly, that this integration (as cool as it is, really 👍) binds an OpenSource web editor for editing TMs/TDs (being defined by an open standard) to a proprietary backend?

Proprietary because a TM repository (which, if I see it correctly, is even able to search in TMs, e.g. for parts of "title", "description", etc.) isn't something which is standardised, or is it?
And I don't see "emporio" being OpenSource, or is it?

If I understand this correctly I want to to be honest: this feels really strange and wrong.

Having some experience/background with the former Eclipse Vorto repository, which is no longer operated and available these days, I personally think that having such a "community driven" centralised repo is a bad idea.
The repo has to maintained + operated by someone.
The API stability of such a repository has to be guaranteed.
When "the whole world" wants to use it, having a single installation in a region will not suffice.

To which conclusion we came for the "repository mess" we also had in Eclipse Vorto:

  • shutdown the repository eventually
  • move models to git (e.g. GitHub/GitLab) repositories
    • let GitHub serve the models via HTTP
    • let GitHub take care of performance, global availability, versioning, access rights, development process for models via PRs, GitHub actions for validation, etc.

I do not say that a proprietary repo should not be added, however I would expect that at least one "open" alternative for including a TM repo in the ediTDor exists before adding a proprietary repo.

I am neither a committer nor a contributor of "Eclipse ediTDor", so this is just an opinion of a fellow OpenSource developer.

@relu91
Copy link
Member Author

relu91 commented Jul 18, 2022

Hi @thjaeckle, thank you for your valuable comment. At vaimee we value open source solutions and we were considering to open source Emporio backend from the beginning. Given the fact that Emporio was founded by @sebastiankb the repository is still private because we are evaluating its future. Therefore, think about this integration as something still in "beta" or experimental.

Regarding, other aspects of your comment we also evaluated other means of storing TMs like GitHub or GitLab, but it felt right to give people a central place where to publish well-known models (like npm, or, as you mentioned, Exlicpse Vorto).

Finally, as you can see in #79 (comment) we are not really forcing to use Emporio people can choose their own service. As you mentioned this probably means additional work inside ediTDor (or even outside) like defining a concrete "standard" API or different fetch strategies. However, this PR is just a first step in that direction.

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

Successfully merging this pull request may close these issues.

4 participants