Refactor Server Connector to make it able to interact with external extensions

[lstocchi]

This issue will be used to discuss and share infos about how we want to split the UI up.

I'll try to summarize what i know, if there are some incorrect infos please write it down.

The goal is to make Server Connector the main UI extension which will work using additional extensions related to a specific type/family of servers. We should end up having Server Connector (main UI) + Wildfly Extender Extension + Eap Extension and so on ... In this way everyone would potentially be able to create a new extension related to a different server and use the Server Connector as the main UI.

Possible implementation -

@jeffmaury proposed that the additional extension (i.e Wildfly Extender Extension) should be in charge of telling the rsp-server which is the new bundle it has to run. So from what i understood, when someone install a new extension (i.e Wildfly), it will tell to rsp-server which bundle it has to run (the one related to Wildfly), it will be loaded runtime and the Server Connector will be able to show the node related to Wildfly Servers and all commands related to it. Am i correct?

The second problem is how we can make Server Connector and other extensions communicate. The idea is to make the extensions register to Server Connector when they are activated. The problem is how extensions are activated in Vscode? In which order? @adietish proposed to make the Server Connector a dependency on the external extensions so vscode should be forced to load them in order (1st Server Connector, 2nd Wildfly, .... ). We have to investigate....

@robstryker suggested to start refactoring server connector code by having in mind that it will work with several external extensions without actually create any of them now.

Hope i haven't forgot anything.

[adietish]

There are several ideas:

@robstryker suggests to separate the UI into a central extension with the servers view and extensions for wildfly and minishift. Those 2 would be some model that talk to their own rsp-server (backend). Upon launching they would inform the central extension that they're present and manage servers created in their rsp-server. When displaying the "Servers" view the central extension would query the 2 extenders and ask them for servers. Those would then show up in the tree that's displayed in the "servers" view.

@jeffmaury suggested a different approach: we'd have a central extension which includes Red Hat middleware products: wildfly, fuse, etc.. An additional extension would contribute minishift servers. In this approach there's a single rsp-server (backend), extensions (minishift, etc.) would add bundles to the single rsp-server making additional server types available.

This 2nd approach has the benefit of a smaller footprint (1 server only) and basically requires no changes in the UI (vscode) portion. The big problem I see here when discussing this with @robstryker is that the rsp-server isnt able to add/remove server types when running. A restart is required.

@robstryker comment your other objections?

[robstryker]

If the main rsp-server is contributed by wildfly extension (as in jeff's idea), and you're only able to disable those bundles by disabling or uninstalling the extension, then you'd be pretty-much unable to disable just the wildfly bundles without disabling the entire rsp-server. So if you wanted to only see minishift/cdk stuff in your RSP, it'd be impossible.

The UI is still basically proof of concept donated from Denis and deserves to be organized and separated as if it's not just glueing new features on top all the time.

The UI should be able to display external contributors' RSPs no matter what language they are written in.

Locking possible contributors into merely extending your implementation of your own protocol is not very open-source friendly.

Allowing random extenders to contribute jars to run inside a single apache felix could ruin the experience for others. For example, if we have the suggested single rsp-server instance with wfly / karaf bundled, and we have new extensions attempt to add to it: tomcat attempts to add 3 jars, minishift/cdk attempt to add 1 jar, ibm websphere attempts to add 2 jars. If the IBM jars have a problem or somehow cause a subtle bug, it could affect the behaviour of all rsp's running in the same VM. Basically, a bug in one extender could cause instability or data loss for all RSPs. It's better if each RSP is isolated in its own process with its own data folder.

[lstocchi]

+1 to Rob's idea. We should keep this as open as possible. If we want this extension to succeed we cannot force users to stick with our protocol, external contributors have to be able to freely decide to use it or not.

[adietish]

• I dont argue against having Wildfly and Fuse in separate extensions, it does make sense to me in terms of design. On the other hand we're productized as vscode extensions for Red Hat middleware. But this isn't a contradiction as long as we can bundle things into a extender pack. +1
• I then dont see how adding bundles would make the whole system buggy, that's exactly what OSGI meant to solve by isolating them against each other. Instability in Eclipse was not caused by problems in the OSGI runtime but by exclusive usage of the display thread. In this sense this isn't an argument for me. -1
• The argument of forcing extenders to use java then is far reached for me. I dont see how an inexistant community would justify this additional work at the moment. Things can be different later and when this happens it'll be soon enough to provide the required effort. -1
• The argument of vscode-adapters being a PoC, I'd agree fifty-fifty. Reorganizing the code can be achieved by refactoring step-by-step with far less effort than a rewrite. -1
• Having a single server then is a big +1 for me, given that this would cut the memomry footprint in half. Didnt we all complain that Eclipse is a memory hog?
• The only real argument against this alternative approach that I'd adhere to is that rsp-server currently can't add/remove server types at runtime. It wasn't designed in this way and I see major efforts to allow this. How can we install/uninstall extensions if it isn't possible while rsp-server is running? We have to restart it. Here one can argue that vscode reloads anyhow when you install an extension.

[jeffmaury]

Let me first establish our goals:

• short term: separate CDK/minishift and wildfly/EAP implementation so that Server Connector will contain UI + middleware products (Wildfly/EAP) and maybe Fuse and OpenShift Connector CDK/minishift
• long term: allow external contributors to implement their own providers in separate extensions.

That's why I initially thought that the approach of having an extension provided one or several bundles would be a good fit for the short term goal even if it was not a universal one. After a discussion with @robstryker I understand that it will open new issues that will not be easy to address so I think the proposal of having several RSP servers is safer. My only concern is that it changes a lot the UI part and I'm worried about the time to implement it.

[adietish]

@jeffmaury what are the new issues exactly?

[jeffmaury]

• removal / adding new extensions that will need the server to be restarted
• once removed the server has still present in the conf area but there is no way to use them
• possible issues related to OSGI if bundles needs other bundles not part of our distribution

[adietish]

Ack on 1 + 2, 3 would lead to the extender bundles not to start bcs of lacking dependencies, basically a matter of packaging. Not a big deal IMHO. I'm fine with both solutions, me thinking that the 1-server approach would avoid running 2+ servers which is bad in terms of memory consumption.

[robstryker]

I honestly believe designing it to be as open as possible is both easier and the correct solution. In the future, if we want to somehow optimize all RHT bundles into a single process, we can investigate that, but I think technically that'd be a hard task for a lot of small reasons.

In reality, the wildfly RSP currently needs only a few meg of memory... maybe 10-20mb? What we should actually be doing here is passing in memory flags to optimize the launch of the felix instance. If we properly pass in memory arguments, we can have 10 rsp processes running in the space that one would have taken.

This app is very light-weight. Memory issues are not currently a significant concern.

[lstocchi]

Closing ... new version of Server Connector can be found on https://github.com/redhat-developer/vscode-rsp-ui