Hi, Zak. I'm one of the contributors who is working on a new feature/service concept integration in Che. I'll try to explain how I see an answer to your questions, but don't take it as a general answer from the whole community. I can be mistaken somewhere, so if someone notices a mistake, please, do not hesitate to add your comments to the thread.
Che 6 agent is a piece of software that adds some functionality to the workspace.
But it is usually added to a workspace with a shell script that installs an agent and its dependencies to a workspace container.
This approach doesn't fit container world approach when nothing should be installed in a container at runtime. Since this approach might be violated in Che we face difficulties in the usage of Che on a hosted containers infrastructures, such as kubernetes or openshift.
Basically installing something into a container at runtime is not a good approach because:
- it may require a sudo access which is unavailable in many infrastructures
- a container may run with a random user ID which is also tricky when you install something at runtime
- agent dependencies may conflict with a user's container. Example: user's app uses Oracle Java 5, agent X uses OpenJDK Java 6, agent Y uses Azul JVM. All of them should somehow coexist in a single container. And they should be somehow installer in the same container which is very tricky.
And apart from that right now Che doesn't allow us to add a plugin to IDE codebase from an agent. Which leads us to a situation when IDE parts of all the plugins we want should be bundled with the basic Che packaging. This approach doesn't allow us to grow Che community and plugins eco-system easily.
So there is an idea to bring new feature/service concept to Che which is called Workspace.Next.
This concept supposes that user defines his own application recipe, e.g. my NodeJS app server in container1 and MySQL server in container2. And he also defines a list of features in IDE he wants to use, e.g. NodeJS support, UI for SQL querying from the IDE, some packaging system support, some VCS support, etc.
Che combines user's app recipe and list of features to a runtime that uses sidecars to provide tooling to a workspace.
In this particular example we could end up running:
- container1 with NodeJS app
- container2 with MySQL server
- container3 (sidecar) with a NodeJS language server
- container4 (sidecar) with a VCS agent
- container5 (sidecar) with an agent needed to provide UI for SQL querying from the IDE
As you might see in this example:
- all the features can be implemented by different authors
- all the features have their own environment and dependencies
- we can set up all the dependencies when docker images for features are built, so no sudo is required
- there is no conflict in dependencies between features because they run in different containers
As to what feature and what service terms mean:
- a feature is what IDE user choose when he creates a workspace
- a service is part of the feature which is developed by Che plugins authors
You can follow discussions regarding designing Workpspace.Next there and eventually even try it when some experimental version of it will be ready.