Re: [platform-vision] Minutes from September 17, 2014

[Martin Lippert <mlippert@xxxxxxxxx>]

Hey Tyler,

let me quickly explain my thoughts about async vs sync.

We have talked a lot about the async architecture that we are exploring in Flux and I think this is an extremely interesting approach that might open up a whole new way of coupling (or decoupling) tooling-related services. But we are still exploring this space and I don’t see this as a discussion in the way “async VS sync” at all. I don’t think there is a tension between sync and async communication at all, we will need both in the end anyway.

I just think that the async approach is interesting enough to be explored in more depth and it makes me think beyond the borders and beyond the established ways of building could apps. This at least helps me to come up with fresh ideas and innovative new ways of doing things. And the first small experiences look promising. Lets explore this space in more depth before we dive into discussions about sync vs async… :-)

Cheers,
-Martin







> The thread below implies the future is primarily one that is asynchronously decoupled. We talk about migrating our products so that microservices and clients are decoupled from one another. Decoupling of microservices is a key architectural principle. What is not clear yet is whether this decoupling is asynchronous, synchronous, or both. It strikes me that we should probably avoid dictating the form of connectivity to microservices, otherwise we end up biasing one technology choice over another.  Users may have different types of experiences depending upon the nature of the connectivity, ultimately allowing the ecosystem to pick and choose how to integrate with services with a variety of technologies to optimize for their particular user scenarios.
> 
> Another few points:
> 1) There are likely going to be three types of microservices, if you will.  Those that deal with provisioning (users, workspaces, resources, accounts, permissions).   Those that deal with workflows (projects, services, sequences, builders, unit testers, runners, packagers).  Those that deal with language services (JDT-style capabilities).  It's easy to think about JDT as a service potentially being a nice way to grow in the market, but these types of core microservices may or may not be accessible outside of an authentication context, for a variety of security reasons.  So, any discussion about a future of microservices probably has to discuss standardization of provisioning & workflow services, too.  This is a bit of a gray area, as again, this wanders a bit into the vendor side of the world. But I again submit that Eclipse as a governing body is one that is expected to release usable, hardened offerings, so we have to account for some of this in the thinking.
> 
> 2) The thread below discussed JDT services.  Che has wrappers around JDT and extended it in its own way, so there is a necessary rationalization that must occur. Codenvy has investments going in ant, maven, gradle.  We'd like to get out of having to rationalize JDT and our microservice approach over the long haul.  Language services should ideally be built once and reusable by Che & Flux at the same time.
> 
> 
> Tyler Jewell -- ceo @codenvy.com -- +1 978-884-5355 -- Schedule Appt. -- Blog
> 
> 
> On Wed, Sep 24, 2014 at 8:19 AM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:
> Greetings all. My apologies for getting these out so late.
> 
> Our next call is today at noon eastern (40  minutes from now, yikes)
> 
> Phone numbers
> 
> North America 1-866-569-4992
> Germany 49-692-2224-6059
> France 33-(0)-17-070-8535
> UK 0800-033-7806
> Switzerland 41-44-580-2115
> Sweden 46-85-063-8386
> Italy 003-902-3604-8268
> 
> Then enter the participant conference extension: 430, then enter pin 4718
> Alternatively, SIP clients can call 430@xxxxxxxxxxxxxxxxxxxx, then enter pin 4718
> --
> 
> In attendance:
> 
> Wayne Beaton
> Martin Lippert
> John Arthorne
> 
> The main focus of the call was to talk about the desktop, but we ventured into a few other corners. I've captured the gist of the conversation below.
> 
> As always, if I've mischaracterised anything, please make appropriate corrections.
> 
> We need Oracle representatives to join this call. I need to keep pushing on this.
> 
> JavaFX is going to figure prominently in Java over the next three years and beyond.
> 
> Java 9 modularity will also be a big part of the future. This will have an impact on our tooling, including the Plug-in Development Environment (PDE).
> 
> Maven needs to be part of the story. Maven support has become one of those things that is just expected in a Java IDE. 
> 
> Aside: we didn't speak about this, but we need to think about next generation build technology. e.g. Gradle
> 
> Refactoring JDT to implement microservices architecture.
> 
> Flux: message backbon; combine pieces. Flux in three years:
> 
> 1. Connections between cloud and desktop tools (sync, migration of projects, integrations)
> 2. Build cloud "microservices"
> 
> "Java Microservices": are these part of Flux, Che, Orion, JDT? Something else?
> 
> Asynchronous integration. Build an integration eco-system.
> 
> Less coupled integration. Move away from monolithic architecture.
> 
> No "IDE" projects. 
> * Web editors and navigation
> * Backend/workspace/provision
> 
> Pick bits and pieces from "feature" projects. "Give me the Cloud IDE" (Flux+Orion+JDT)
> 
> Running/hosting Cloud IDE
> * Not on EF infrastructure
> * Eco-system provides the hosting
> * Partial hosting by EF of some microservices (core messaging/front ends); stateless services.
> 
> Wednesday afternoon meeting at EclipseCon Europe (followed by dinner and drinks). Wayne will sort this out.
> 
> Platform was "the" integration point. Much more fragmented world now. Refactoring Eclipse to fit into the polyglot tooling environment.
> 
> Make JDT usable in other ways. Plug into other editors. More flexible/integrate into other tools (e.g. Tomcat integrating with ECJ).  Able to fit into other tooling environments. Interactive tooling is more challenging to pull apart.
> 
> Java/JavaScript is "just an example". Polglot node.js/ruby/php/c
> 
> Wayne
> -- 
> Wayne Beaton
> @waynebeaton
> The Eclipse Foundation
> <ECE Friends 480x60.png>
> 
> _______________________________________________
> platform-vision mailing list
> platform-vision@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/platform-vision
> 
> 
> _______________________________________________
> platform-vision mailing list
> platform-vision@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/platform-vision