Re: [che-dev] Sidecars & Extensibility

[Thomas Mäder <tmader@xxxxxxxxxx>]

As I understand it, we'll need to route pretty much anything through the theia container anyway, since it will be the only one publicly available.

/Thomas

On 02/26/2018 06:42 PM, Vitalii Parfonov wrote:

With extension like side-cars don't forget v about same-origin policy for browser client

26 лют. 2018 р. 19:35 "Thomas Mäder" <tmader@xxxxxxxxxx> пише:

Hi Yevhen,

The idea I had was that we could do what the installers do, but instead of downloading & running a script, we would rebuild the "Java language support" image. Basically, you click "Checkstyle support" on the workspace configuration page and the system goes away to make that happen.
If we don't have mutability inside the containers, we might have to mutate the containers themselves.

/Thomas

On 02/26/2018 01:45 PM, Yevhen Ivantsov wrote:

Is it technically possible to have one universal image with one jdt.ls build having all extensions? This way we will avoid creating buildConfigs or docker builds (on docker infra). IMO it's ok if a plain java project does not need all jtd.ls functions.

Pre-building stuff either before container start or in the runtime will dramatically impact UX.

Another question: do you have any strategy on how language servers will be initialized in Theia and whether or not we will use Launchers? Or the client will assume that a language server is listening on a tcp socket:port in a dedicated sidecar? 

The reason I am asking is because current Che implementation is rather difficult to extend - adding a new file extension for a language server takes a while to figure it all out. In other words, are we still up for a way to add language servers without having to rebuild? 

On Mon, Feb 26, 2018 at 2:23 PM, Thomas Mäder <tmader@xxxxxxxxxx> wrote:

Hi folks,

In preparation for diving into Theia development next sprint, I've been thinking about how sidecar containers play with our vision of Theia extensibility. I'm trying to get my understanding aligned with everyone and feedback on my ideas, so feedback very welcome.

As an example, I'm going to use jdt.ls, but I guess the issues could apply to other environments, as well. The particular thing about jdt.ls is that it is extensible. So, for example, if I want basic java support, I need jdt.ls. If I want to add debugging, I'll need a couple of eclipse bundles developed by microsoft. To add our Che-specific extensions, you need another set of extensions developed by Red Hat.

What I'm getting at is that we need n plugins, which we might not know in advance. In the case of jdt.ls, they all need to run in the same process. This means we'll can't just build a single sidecar container and run that, we'll need to install stuff into it.

One way to do this would be to keep our installers, but target the language-support sidecar. This would run into the problem of having no sudo rights on Openshift, IMO.

The other way to do it would be to build a new image in order to add a new component to the sidecar. There would have to be some plugin API to contribute such components.

thoughts? thx.

/Thomas
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev

--

EUGENE IVANTSOV

Red Hat 

eivantsov@xxxxxxxxxx   

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev