Hi Kaloyan:
The use case that you are talking about is clear.
There are two ways to achieve what you are seeking - with and without docker. In both cases, a Che workspace always requires a runtime. The workspace cannot start without its runtime, and you cannot open the IDE without it. So the only question is whether you are going to use a default runtime (Docker) or create a different kind of runtime (localhost). Che is shipping with an abstraction layer, called Machines, which can be extended to different types. Machines are used to provide runtimes to the workspace. We have the Docker machine as the default implementation. In 4.2, shipping in a couple weeks, we'll have an SSH machine as well. We have not implemented a localhost machine, but it is possible to override our interfaces and to create custom machines of your own.
In all cases, regardless of the machine, you can programmatically create / destroy workspaces. Once you have the type of machine that you intend to use, you can launch the Che server and then use the Che APIs to generate (or load) a workspace. Once the workspace is loaded, you can then provide the user the IDE. You could have the process that starts the che server & create the workspace run as part of a daemon, for example.
In the docker configuration, you need to have a docker daemon on your AMI along with the PHP image that would be used to power the Che machine. Docker can instantiate containers quickly, so using Docker would generally not be the bottleneck in the loading.
So to do this, would:
1. Create a build of Che that removes any use of the dashboard.
2. Get a Che image on your AMI in your local registry.
3. Start the Che server in a daemon.
4. Call the Che APIs to create a workspace.
5. The workspace will start with the embedded terminal & ws-agent.
6. Then you have this workspace ready to present to the user on your own terms.
You'd want to set the workspace idle timeout to -1 or a very large number, as essentially the workspace itself is now running as a service.
Doing this without Docker would involve writing a new Machine interface. That is getting into code. But even once you had this, it would be an optimization, as the workflow cited above would still be the sequence of steps to follow.
Tyler
