The Flux project is a project in the Eclipse cloud development area and it aims at bridging the gap between different worlds, like you might know that there are already emerging cloud IDEs and they live inside the cloud, and they are totally disconnected from the tools that you have on your desktop at the moment, like Eclipse IDE, IntelliJ whatever. So it’s usually quite hard for people to say “Ok, I am now ready, I jump over the wall into this cloudy space, I use a cloud IDE and throw everything away that I have on my local machine like the desktop IDE or all my local tools that I use on the command line and things like that, and everything lives exclusively inside the cloud”.
So what Flux is doing and is trying to do is to bridge this gap it tries to connect the different bits and pieces, so that you end up with something like a unique space, so for you it feels like you're working from your desktop IDE on your project, you can connect your project to the cloud, they are still local on your machine but at the same time you can start working on those projects with a web IDE or with a cloud IDE or with a web browser from anywhere in the world. But whenever you work on that and you go back to your laptop or your desktop machine, it’s the same, you added some files over here but all those changes appear immediately in your desktop IDE as well. So you can move back and forth and jump between those worlds whenever you want, you do not have to jump over the wall anymore, you can use both at the same time. And this helps you to maybe slowly migrate over from desktop IDEs to cloud IDEs in the future, without really noticing that you are moving towards that new world which I think could be very promising.
2. So it’s kind of like Google docs for source code.
Yes, it’s a little bit, in the beginning it feels a little bit like Google docs for source code, because if you start editing your source files in a web browser UI, all those changes and edits are being reflected in your desktop IDE as well, so this kind of bridging the gap is not only based on synchronizing files, between the cloud and your desktop IDE, it is also based on syncing live typing which is very interesting and useful, because - and that’s the second part of Flux - we use this syncing mechanism under the hood as an enabling technology for services that are running inside the cloud, that can help you to work with your source code and can do additional stuff for you. Because for example in your desktop IDE you have I don’t know, if you are working with Java, you have syntax highlighting that’s easy, but you have reconciling, errors and warnings, content assist, all that stuff for Java, and that’s a heavy implementation, you do not have that inside a web IDE and I personally do not want to re-implement a Java compiler, in JavaScript just to let it run inside the browser UI.
I would like to have a tiny little service that is running inside the cloud, that is producing those features for me, like providing me errors and warnings while I am typing, giving me content assist, giving me navigation, refactorings, all that stuff, I don’t really would like to re-implement all that stuff inside a browser UI. Having that as a service inside the cloud makes total sense to me because that’s way more powerful than running on your machine, but to enable that, you need to have some mechanism that this service can actually work and see the same stuff that you are working inside a browser UI in your desktop IDE and that’s why we have this syncing in place.
3. So it is like pair programming where the other part of a pair is a robot?
Yes, it’s a little bit like pair programming with a robot while this robot, this service or this micro-service may be giving me additional stuff, is giving me additional feedback, helping me all the time, maybe in the first place doing the same stuff that the desktop IDE is doing for me at the moment, but in the future could of course do more, like analyzing all projects inside your company for you and giving you feedback while you are working on your code, telling you “Oh, you are changing something, wait a second - if you are changing this interface this change would affect five million other projects inside your company because this service is doing this heavyweight lifting for you, analyzing, indexing, whatever is inside your company for example”. But I should mention that this live syncing stuff and this real-time syncing while typing, you mentioned Google docs for code, it can be used for collaboration, so I can invite you to my code and we can both work on my file inside the editor, in the browser, but it’s not meant as a replacement for version control or something like that.
People are often confused by that because Google docs is one thing in the cloud and everybody is working on this one thing, you do not have your version or my version it’s just one thing. And working on source code you usually would like to have your file and I can invite you to my file and we can both work on that but you would also like to have your stuff and your work environment and your version of our project maybe, inside your space. And that is still being enabled by Flux, it’s separate, it’s not meant as a replacement for Git or something like that.
Yes, I think there are endless possibilities, it sounds a little bit like advertising but the more I think about those services, the more ideas are coming up in my mind because there can be services for let’s say pure language tooling like there’s a JavaScript service, there’s a Java service, there’s a Scala service doing errors and warnings for Scala, there’s another service doing content assist for Python, totally different ones, but there can also be other services like what you mentioned, like this one service saying “Whenever you press save on file, it runs a unit test for you in the cloud, it runs the CI build, it triggers a notification somewhere else in the world, or it uploads your changes to a platform as a service installation where you lively update your application while you are working on it inside the browser” for example. There could be services doing spellchecking, there could be services saying “Oh, I connect everything to GitHub as a repository backend so whenever you change files it automatically creates a branch in GitHub and stores everything in GitHub for you”, for example thousands of possibilities, at least from my point of view.
Alex: And also these services I guess can be horizontally scalable as well.
Yes, I think they can be scalable but I think the interesting thing is that those services are pretty autonomous, so they can decide on their own what they would like to do. So there can be services that say “I am interested in Java files from Alex only” or “I am interested in all the projects inside the company” or “I am multi-tenant: I can work for thousands of users" or "no I can work just for one user and you need to have thousands of instances of this service for thousands of users” - that’s a thing that the service can decide on its own which makes it pretty flexible I think.
Not at the moment, the implementation that we have is a prototype so it’s not production ready code yet, and the one thing that we started with is Java services, and doing stuff for Java, but it is decoupled from the editor side, so the editor in the web that’s based on Orion and the syntax highlighting is done on the client side, using the Orion stuff doing syntax highlighting involving different languages, but it is not calling the Java service, the Java service itself is kind of connecting to this Flux system and says “I am interested in Java, I can do stuff with Java and give stuff back” but we haven’t implemented all the different language services, it’s more of a proof of concept saying “This is how things should look like, now you can join in and do your own language service, if you want”.
6. How does Flux work under the covers and how do these things find and connect to each other?
The Flux architecture is pretty different from any existing architectures, because it is based on messaging only, so there are no - you would expect there to be REST APIs and REST calls and http involved and stuff like that which is not the case, there is no single REST API involved at all. All the different bits and pieces are connected with messaging, so there is one messaging bus, one messaging system and you can connect with those messages and those message channels, and there you can receive and send messages, and that is basically all. On top of this backbone for example as I said there is file syncing that’s done with sending messages forward and back so whenever you change a file, you are sending out a message saying “I’ve changed a file” and someone else is receiving this message “Oh, I am interested in syncing this file”, he can send you a message back saying “Give me your change” for example or “Give me the new version of the file”, and therefore all the people that are interested in for example participating in this file syncing, they are all just connecting and listening to the same set of messages, and doing their part on their side.
This live typing is exactly the same, and these errors and warnings doing reconciling is working on the same level, the service is doing the file syncing so it listens to these files messages back and forth, and at the next level it says “Ok, whenever there is a change of this file coming in I analyze this change, and I send back a message saying there is an error and warning for this file, and someone else can say I am interested in messages about errors and warnings, so I display them”. And the same happens for example for content assist, the editor says “I need content assist for this file at character position X”, sends out a message, and then more or less forgets about that.
And then someone else says “Oh I am able to do content assist for this Java file, so I do that for you” and that guy sending back the message with the result for the content assist and the editor can then listen for those messages and say “Oh yes, I asked for content assist now that guy is sending me content assist at this place” which sometimes feels a bit strange because it’s not this synchronous way of - you call an API you wait for the result and then you get the result back and then you can do something with it - it’s more this you send out a message, and you wait for something to happen, and it could be that someone is sending back an answer but it could be that five guys are sending you back an answer or no-one which feels a bit strange when you are programming against it, but I think it opens up a lot of possibilities because it’s so much decoupled, it doesn’t matter, it doesn’t matter where a service runs, it doesn’t matter what language you are working on, like there is a cloud, and Flux is running on Amazon I could even run it on my local machine, connected to this Amazon instance, and everybody who is connected to this Amazon instance could use my service, could benefit from that, because my service could say “I sync those files from those guys I do the analysis, sending back the answers” so it’s extremely flexible. So services could run in different data centers across the world, maybe running on my local machine for the world is not the best idea, but it shows the possibilities and the high decoupling between the services, which is good and bad, but it’s at least interesting.
That’s an interesting question, we have chatted about that at EclipseCon here, because at the moment they are pretty disconnected so there’s Orion, there’s Che, there’s Dirigible and there’s Flux, and Flux is a little bit connected to Orion because we implemented the adapter for that, but the long term vision for that is to create one unique vision and one unique story out of those projects and technically they do not fit together at the moment but the plan is to move Che towards more of a backend service, creating this workspace's projects, doing the provisioning, running services inside the cloud for you so it’s more of this heavyweight backend lifting that Che is doing.
Orion is very much focused on the client side, running inside the browser, doing the UI for you, the UI side, so in the future I think, and that’s what I expect, is Orion will run on the client side while we use Che on the backend side do the heavy lifting and Flux will be the part a little bit in the middle to do some better communication between those two and connect those to existing desktop tools, so that you do not have to - as I said in the beginning - jump over the wall and use either Orion, Che or your desktop tool. And Dirigible as a fourth project in the cloud project will be kind of sit on top, as an extension because Dirigible is a little bit like the 4GL kind of tool for creating applications without programming everything in Java, so using higher level concepts, that seems natural fit for turning this into an extension of the underlying platform which then consists of Orion on the client side, Che on the backend side, and Dirigible on top of that as one example for how to extend this underlying technology.
There is a website at Eclipse, it is a project at Eclipse, so you can go to http://eclipse.org/flux/ then you will get a welcome page for the Flux project, you can take a look at the repositories that are at GitHub so under the Eclipse organisation at GitHub, there is a developer mailing list, you can just go there and ask questions and get answers, hopefully you’ll get answers, maybe you will get other questions back because nobody will know. There is a wiki page describing how to get started, so how to download everything and run everything on your local machine, and get started and we would be very happy to invite new contributors and even new committers to the project, so if people want to work on that they would be very very very welcome.
Alex: Martin Lippert, thank you very much.
Thank you.