There is a 50/50 chance I will not be able to dial into the ECD session today. I will hopefully be settled in a quiet place within LHR. But it's LHR, so that means its unpredictable and could very well still be standing in a security line that resembles Disneyland on a hot summer day.
Attached is some additional information about how the Codenvy system works and changes we are making for our upcoming generational release. Most of this is functioning on acceptance servers now. I expect a full beta in a couple more months.
In this next generation system, a few things:
1. We will have a clean machine abstraction with an SPI. Machines can be launched as Docker or OS, or you can provide your own such as a Mac Mini, Mainframe, etc.
2. We will have a reverse proxy implementation that allows persistent & pretty URLs for machines w/o exposing ports. Allows us to create privacy policies that not only apply to projects, but propagate down to machines.
3. There will be a distinction between development and runner machines. Development machines will be bound to a workspace and will have 2-way binding to all of the projects contained within the workspace. Worksapce machines will have their dockerfiles editable by users, but lifecycle managed by Codenvy. They will be snapshot with saved state, and quietly booted / shutdown based upon user actions. Users will optionally be allowed to have runner machines which run in an enviornment of networked connections, such as having a 3-tier application in 2 source code repositories deployed in 3 machines. This combination of workspace & runner machines offers the user a very fast experience combined with enterprise module flexibility and scale.
4. Commands will be injectable into various machines either from a terminal or by the IDE. Today commands are embedded within a dockerfile, which creates some overhead to their booting before the command is executing.
5. Custom developer services such as Java content assist, terminal exposure, maven build intelligence that are authored as Che extensions will be bindable by our system into a developer machine. This allows remote clients like Eclipse or our browser IDE to dynamically detect and act on certain services. For example, we'll be supporting all of Eclipse's refactoring & content assist in 4.0. The content assist service is authored as an Eclipse Che extension that gets bound into a machine by Codenvy. When a developer creates a project of type Java, the system knows that it needs Java content assist. it looks up this extension and binds the content-assist service into the machine, which then allows the IDE to natively provide these capabilities like refactoring, method generation, error detection. It is this sort of binding that allows a single user within a single workspace to get access to unlimited resources while still providing a localhost-like feel.
All of this will be controllable via REST API which is also provided in Eclipse Che.
If you are interested - we can get your team some demos of the new content assist, various machine behaviors, persistent URLs, etc.
