Q&A with Ken Walker

Eclipse Orion – what’s next after 1.0?

Chris Mayer

A month on from its initial arrival, Eclipse Magazin’s Diana Kupfer sat down with project lead Ken Walker to discuss its impact and the next moves for Eclipse Orion

We’ve been monitoring the progress of Eclipse’s browser-based IDE spinoff Orion eagerly for some time now. After months of milestones and tinkering, the team shipped Eclipse Orion 1.0 bang on October’s self-imposed deadline.

Now with a solid base nailed down, thoughts turn towards the next major release, 2.0, in February. By the looks of this week’s opening milestone, a lot of effort seems to be going towards a node-based Orion server.

Eclipse Magazin’s Diana Kupfer sat down with Project Lead Ken Walker to talk more about the web-based IDE and what else is in store…

Orion 1.0 was released just about a month ago. Congratulations! Was this difficult or has development gone smoothly so far?

Walker: The Orion team managed to ship on time each of our pre-releases in February and June of 2012 and meet our October goal of shipping a 1.0. Having a 1.0 release so soon after a summer where developers are supposed to be relaxing was the most challenging aspect, but the team really pulled together and we’re all quite proud of what we have running at OrionHub.

A basic, but important question: why do they think that a browser-based IDE is superior to a desktop one?

Walker: Many developers spend a significant time downloading their IDE, finding and setting up the plug-ins required for their current development task. If they head home and decide to work on their iPad while commuting by train or otherwise and have no access to their pristine setup, they’re pretty much out of luck. Orion envisions a scenario where developers can set up their workflows around projects which combine resources, libraries, repositories and deployment scenarios to get their tasks done. Each of these tasks and their associated plugins are combined client side in the browser, from wherever you are accessing Orion.

Obviously, Orion has come a long way since last year, and the features/improvements of the past year are difficult to put in a nutshell. Still, what are your personal top five new 1.0 features?

Walker: A new look and feel for our UI. Significant work was done to make Orion a more compelling place to code, free from the clutter of a standard IDE, but still customizable through themes. We still have a lot of work here, specifically around the concept of Projects but we believe we’re on a good trajectory. Inclusion of the Esprima JavaScript parser into our core libraries. This best of breed library really helps in areas around content assist and providing parse trees to plugins. Adding an extensible Shell for command line zealots. Out of the box we provide basic capabilities but this Shell can be extended by plugins to do things like provisioning, or like we’re doing for 2.0, launching Node.js applications. Improved Content Assist is a feature enabled by both the Esprima parser and the Doctrine libraries, but we continue to push on language tooling. Great Git Support. We completely redesigned most of our Git pages, added dynamic loading to the UI, plus added merge/squash and a very nifty code review feature.

A year ago, Simon wrote about the four guiding design principles of the Orion project in Eclipse Magazin: using native browser capabilities, keeping it task-oriented/resource-focused, being performant and lightweight and having low barriers to entry for adopters. To what extent were you able to adhere to these guidelines?

Walker: The Orion team has continued to meet these four design principles through the 1.0 release. For the future, the team is investigating the concept of Projects and this may add slightly more information or context for a page but we don’t believe it will cause us to digress from these guidelines. Adoption has been great in the community. At EclipseCon Europe we were given many demos of integrations that we weren’t even involved with. So it shows that Orion is easy to adopt both structurally and though use of our documentation.

Scratch Pad, Style Editor and the use of the identity system Persona are some of the results of the ongoing collaboration with the Mozilla DevTools team. How, when and why did this collaboration began?

Walker: The collaboration with Mozilla began when Mihai Sucan (from Mozilla) investigated the available web editors and decided that the Orion editor was the only one that could support IME and Accessibility properly because it uses the content editable support from the browser.

So he approached us and started logging bugs and submitting patches. The Orion team has also consumed both the GCLI for our Shell and Persona as a login authentication because it’s extremely easy to integrate and understand (it’s just your email address) and also that it is managed by an Open Source group.

…and what other collaborative projects/components are planned in the future?

Walker: Through 2012, Orion has had great collaboration with committers from VMware. They are producing the Scripted editor for desktop use, are consuming and contribution to Orion to achieve their goals. There are also other Eclipse teams like Xtext working on a cloud version of their tools and the Stardust project looking to integrate their BPM tools as an extension to Orion.

Orion has had wide adoption apart from Mozilla. You must have heard many reasons for this great interest in Orion – which ones did you hear most often?

Walker: One of the main reasons for adoption is the leading edge approach to extending the platform through plug-ins right in the browser, vs. having to do this only on a server. The team has done this in a secure manner and it’s very easy to write an extension to Orion. The Orion editor, completely written in JavaScript, is also a key component that projects pick up. It provides the framework for content assist, highlighting, validation, among other features like i18N support.

Part of your plans for the 2.0 release in February is to work on deployment solutions because OrionHub is not going to be the hosting provider. Any specific plans yet?

Walker: That’s not completely what we meant, we mean that OrionHub is not funded to the level where it should be considered a corporate hosting site. OrionHub is a testbed of our milestones and release candidates. What we want to work on is getting code out of your Orion site onto hosted sites through as many supported means that we can. This also includes looking at a Node.js based server that as a simple node package manager install, can provide live editing, debugging and running of a Node app on whatever platform you have running node.

Same for offline support – how will this be achieved?

Walker: Offline support will require leveraging client side caching and app-caching to the full capabilities of modern browsers. We already support an HTML5 local file system, so the content can be made available offline, but offline could also leverage a small Node.js based solution offering access to your whole or a sandboxed portion of your file system.

What else is particularly noteworthy regarding the 2.0 release?

Walker: There are at least two features that are major changes to Orion in 2.0. The first is the introduction of a Project concept. A Project will be the aggregation of resources, libraries, repositories and actions for tasks such as deployment. While we won’t be able to get all the Project features we want in 2.0, we’ll have a start on this idea by February. The second major feature is support for Node.js. This doesn’t just mean supporting writing Node apps, but actually porting portions of the Orion server to Node. At the moment we have the capability to use the node package manager (npm) to install Orion and that’s all that is required. You start Orion and you can edit, install plugins, and launch Node applications wherever your Node runtime is located be that on your desktop or on a Raspberry Pi.

Do you have enough developers to achieve your next goals or are you looking for help?

We can always use more developers. Working in an Agile manner with short delivery time frames, it would be easy to onboard new developers. There is a real uptake in the community and we’re seeing an influx of pull requests for bugs. The team has been marking our bugs as “help-wanted” indicating these bugs are excellent candidates for newcomers to Orion.

Inline Feedbacks
View all comments