-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Extension Mechanism #28
Comments
If we want to allow all the flexibility of adding additional UI plugins in the form of Inversify modules, we will need to run webpack on the server side whenever a plugins gets added or removed and reload the application. |
We had a small brainstorm about the extension system, note that this is We agree that:
Open questions: As far as we understand inversifyjs can be used to compose applications However do not see how inversify could be used for runtime extensions ? Clarify differences between web frontend and electron. What is needed for What would be a way to prevent a plugin to freeze the whole application Backend should be able to install from a repo directly ? Or possibly Can extensions extends extensions ? with services ? |
Sorry, I missed your comment (should have read it before yesterday's meeting :) I agree with the goals, you listed. But as mentioned yesterday, I think we can achieve this with compile time extensions. I think we could have an extension-registry on the backend, that knows the current configuration (list of enabled extensions for frontend and backend) and is capable of rebuilding the application if the configuration changes. For the frontend it means we would run webpack with a new configuration. The client would need to reload the browser, afterwards. An extension could simply be an npm-package, with a certain tag (e.g. #theia-ui-extension and #theia-extension). The registry would then use npm-find and filter on these to show the user the available extensions. We download/install them through npm. An extension package would specify a main entry file which exports one object (or an array, if we want to provide that) of a specific type (E.g. TheiaExtension), which has lifecycle call backs and provides inversify modules. |
I have a question about backend extensions, does the install and uninstall
part mean that on the next server restart (or create after some strange
state) the extensions should already be installed?
So if the server will raise from docker image, the extensions should be
already there? Or on every reboot we will install them again? If no, that
means that we have to add parts of config to the dockerfile and for every
client the image will be unique, not generic for everyone.
Thinking of this, it's better to have one generic image with basic setup
without extensions and blank dockerfile that extends it and is unique for
every user. In this case we will be able to easily change the basic part
without touching user config
…On Apr 26, 2017 11:31, "Sven Efftinge" ***@***.***> wrote:
Sorry, I missed your comment (should have read it before yesterday's
meeting :)
I agree with the goals, you listed. But as mentioned yesterday, I think we
can achieve this with compile time extensions.
I think we could have an extension-registry on the backend, that knows the
current configuration (list of enabled extensions for frontend and backend)
and is capable of rebuilding the application if the configuration changes.
For the frontend it means we would run webpack with a new configuration.
The client would need to reload the browser, afterwards.
For the backend we would only need to install and restart.
An extension could simply be an npm-package, with a certain tag (e.g.
#theia-ui-extension and #theia-extension). The registry would then use
npm-find and filter on these to show the user the available extensions. We
download/install them through npm.
An extension package would specify a main entry file which exports one
object (or an array, if we want to provide that) of a specific type (E.g.
TheiaExtension), which has lifecycle call backs and provides inversify
modules.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/TypeFox/Theia/issues/28#issuecomment-297318144>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AHBGkrm9N05H_gNpFvnGlxw30f2_hakvks5rzw8HgaJpZM4Mz2fa>
.
|
@svenefftinge Yes that sounds resonable for the installation of an extention at least. I'm not sure about enable/disable however seems like recompiling for that would be too slow. Could there be a way to allow that to be a runtime operation with the inversify way ? @Alspaladin It seems to me that what someone wants to do in their docker config is their choice, having the extentions there or not. The way I see it, the frontend has the master configuration for the extensions, not the backend so while you can save time by preinstalling common extentions in a docker container Dockerfile. Once the frontend connects it will install/uninstall what its configuration says should be there. As an admin the best scenario I think is to have a blank Dockerfile, set the user home directory outside of the docker image and distribute a git managed recommended config to the users for the frontend. That way kinds are kept generic for the admin and the users don't have to reinstall stuff all the time. |
Talking with Marc-Andre we had some concerns about API versions. Say we release version 1.0 and extension Foo depends on a Theia interface defined in version 1.0 We would need to version the interfaces and have some kind of deprecation strategy to move the extensions to the new APIs and avoid non-compatible extensions to load. Any ideas on how to do this ? I just read in your 1st post " Defining APIs and their lifecycle is a separate topic." So I guess we could create that topic :) |
I would like to reuse npm as much as possible, so also for versioning. It is generally very weak compared to e.g. OSGi but it is the standard thing in JavaScript land. For recompiling without further optimizations the current build time is 2 secs on my machine. Since we are talking about installing extensions, I think a couple of seconds to install them would be acceptable. That said there are plenty of possibilities to optimize. E.g. we could just use runtime module resolution, so the browser would send multiple requests for the individual extensions. In general, a quick reload of an application seems to be much simpler than dealing with (un)loading of extensions and their services at runtime. The latter will require us to introduce and listen on all kinds of additional lifecycle events. I don't think that is worth it. Re: docker. We should on no level make any assumptions on docker being used as the runtime. |
@svenefftinge Right I had not though about npm so much but looking at node-semver it sounds quite flexible. Re: recompiling, yes I agree I was just wondering if enabling / disabling could work a different way but I guess it will be the same as install/uninstall just without removing the actual extension files. |
Just to update talking with others, I don't think so anymore, the backend should have the master config, given that it doesn't make sense for the web app front end to have such a config... |
Just to document a discussion we had with @svenefftinge we could have a first step where the extensions are specified in a config file and the app is manually recompiled. This would make the development of extensions possible with the packaging we ultimately want with less of an effort than the full registry solution. |
I am going to use npms to look up packages instead of |
Confirmed by npmjs support that there is a delay about 24h in search API + advises how to index ourself: https://github.com/npm/registry/issues/198#issuecomment-319213770 I will still go with npms since it looks like they already do indexing but in the long run we can look into suggested indexing alternatives. |
Fixed with #391 |
Signed-off-by: Yevhen Vydolob <yvydolob@redhat.com>
Theia should be extendable in the following ways.
At the core of Theia we use dependency injection (inversify) to contribute functionality to existing hooks and also to provide new hooks. A plugin should contribute an
inversify
module, that is then just added on start up.The text was updated successfully, but these errors were encountered: