Eberhard Wolff talks with Martin Lippert of Pivotal about the Eclipse Flux project. This projects is in its early stages — and has a very interesting goal: It aims to put software development tools into the cloud. It is a lot more than just an IDE (integrated development environment) in a browser. Instead the IDE itself is decomposed into several services that might run on your local computer or on a server somewhere on the net. Service might be complex and e.g. provide a continuous integration environment or just a feature like code reconciliation. To create such a system an asynchronous Micro Service architecture is used instead of the the Eclipse Plugin model. The result is an open platform that redefines how IDEs are implemented and architected — and as it is not tied to Eclipse it might change the whole IDE landscape. We discuss what this approach means for users as well as how it is implemented. Flux is also an interesting case study that shows how even highly interactive applications that need low latency can be implemented as a widely distributed system with asynchronous communication and loose coupling.

Martin,
I’d like to learn more about the architecture of the messages themselves. Does it use a DSL? is there a specific schema that will be implemented? is it based on OSGI messaging that you mentioned? Where could I read about the plans for this?
Thanks,
Craig

Hey Craig, there is a bunch of resources and links available from the Flux wiki page at Eclipse: https://wiki.eclipse.org/Flux. I also documented the messaging architecture that powers the prototype implementation a bit on the wiki and I would also recommend to take a look at the prototype code that is in the Eclipse Flux repo.

The messaging has nothing to do with OSGi at the moment and I don’t think it will in the future. It is very much focused on doing asynchronous messaging across a wide variety of networks and end-points, most of them not being based on OSGi or even Java. Therefore the messages are JSON formatted at the moment and sent over a websocket channel. That will probably change in the near future when we are moving forward to a more sophisticated implementation, but I don’t expect OSGi to play a major role in here.

The schema of the messages is not formally defined yet, since we are still experimenting with the exact protocoll that those messages will be used for. So there is no DSL being used at the moment. If you want to learn more or even get involved, feel free to start and/or join discussions on the flux-dev@eclipse.org mailing list and feel free to join the weekly team calls. They are open to the public and you will find the details on the Flux wiki at Eclipse.