Development
Web-based development with Eclipse Orion
Web developers should have web-centric tools for development. That seems like a perfectly logical thesis, but in actual practice web developers are chained (figuratively) to their desktop with tools meant for standard development. The Eclipse Project is looking to change that with Orion, a web-based set of tools for developing web applications. It's still in very early stages, but is showing a lot of promise.
The Eclipse project announced Orion in early January, and pushed out a hosted implementation in March. The initial contribution came from IBM's original Eclipse team as a "seed" to kick things off. The latest release, Orion 0.2 M7 was released at the beginning of May.
Orion is completely separate from the Eclipse IDE that many developers are already familiar with. Orion is a set of loosely coupled components that are written in JavaScript (on the client side) and a server written in Java (using Jetty and Equinox). According to the Orion architecture overview, the vision for Orion is to feature browser-based tools that interact with data stored locally or to access data hosted in "the cloud" via REST APIs. The client is dual-licensed under the Eclipse Public License (EPL) and Eclipse Distribution License (EDL). The server is available only under the EPL.
The proposed use cases for Orion are quite diverse. The scope for Orion is any kind of web development — from single-developer scenarios developing simple sites with PHP, JavaScript, HTML, and CSS, to collaborative development of JavaScript libraries, to development of frameworks like Orion itself that include server-side Java components and the JavaScript, CSS, and HTML client pieces.
This isn't the first web-centric effort from the Eclipse Foundation. A web-based Eclipse 4.0 prototype was demonstrated at EclipseCon in 2008. That was abandoned, however, and Orion is a new codebase that contains very little from the current Eclipse codebase.
Given that the world already has plenty of IDEs (like Eclipse) and development tools, you might wonder why it's necessary to create one that runs in the browser. Eclipse developer Boris Bokowski has a simple answer to that — Orion isn't meant to be an IDE. According to Bokowski, developers already use a lot of web-based software as part of development: Bugzilla, code review tools like Gerrit, reading documentation online, and code repositories with web-based tools like GitHub. But then they use desktop tools like a text editor or full-blown IDEs for actually coding and debugging — which isn't optimal. Bokowski describes it this way:
For this to make sense as a way to develop software, you'd want all those browser-based tools to work together. Ideally, you'd want something similar to the tight integration you typically get from a classic IDE, but without building another IDE. We want to build something that works well with existing tools out there on the web, and we cannot ask others to buy into a new programming model that we may come up with. Therefore, our approach has to be based on well-proven web architectures - using hyperlinks to navigate between different tools and resources, making data accessible in a RESTful way, and using web technologies like HTTP, JSON, OAuth, OpenID, and others.
What's the advantage to that? Generally the same advantages that one derives from most web-based applications: Developers don't have to install an IDE, nor maintain one (assuming they're using a hosted instance provided by someone else). It fits well with web development, since the developer is already using the browser for testing and debugging. Being developed in JavaScript means that its target audience — web developers — should be able to extend and contribute to the project as well.
Orion is also being designed to be very extensible, with a plugin architecture that's already working. However, Orion handles plugins a bit differently than you might be used to. Instead of installing a plugin on the server where Orion is hosted, Orion plugins are links to external sites that have the JavaScript for the plugin. This eliminates the need for developers to have server access to install plugins they wish to use. Instead they can simply link to (or create) plugins and point to them.
The plugins, when installed, are persistent — that is, developers won't have to re-install plugins after pointing Orion to them the first time. One thing that seems to be missing, though, is any kind of vetting of the plugins. At the moment, Orion doesn't seem to have a plan for ensuring plugins are not malicious or providing a repository of known-good plugins. One hopes this will be added if the Orion community grows.
The Orion developer principles recommend reusing existing tools rather than inventing new ones whenever possible. Case in point, Orion is working on Firebug integration, and having Firebug invoke Orion as an editor.
Getting and using Orion
Developers have a couple of options for using Orion. One is to sign up for the hosted version of Orion, called OrionHub. You might want to hurry, though — according to the beta announcement, the service is open to the first 5,000 developers who sign up. Additional accounts may, or may not, be made available as the Orion community expands — the announcement doesn't make any promises.
Alternately, you can download and install Orion on your own machine. The project offers builds for Windows, Mac OS X, and (of course) Linux. It is a slightly more involved affair than simply signing up for OrionHub, but it does provide more control and is much better for those who would like to hack on Orion as well as make use of it. One note of caution for those running their own instance of Orion — right now there's no upgrade or update functionality in Orion. This means that, as a rapidly developing project, you'll probably want to update it often but you'll be on your own for backing up user accounts and data. There's a little guidance on the wiki about wiping server data for demos of Orion that you can use to figure out how to back up accounts and data, but it's all up to the user at this point.
After spending a bit of time with Orion to see what it has to offer, I have concluded that it has some growing to do before it's going to be suitable for many users. And, in fact, the FAQ for Orion says as much. Orion isn't yet ready for "real work," though the Orion team is using it themselves. Orion only recently gained things like syntax highlighting for HTML and still lacks the content assist (code completion) for JavaScript. Some content assist is available for CSS, but it's a work in progress. Eclipse uses Textmate's grammars for highlighting. Those interested in hacking in highlighting for their own favorite language can find details on the wiki.
Orion does have quite a few features for working with Git repositories, and some basic functionality for pushing changes from OrionHub into GitHub projects. But it's still evolving. You need to use another Git client to actually push or pull changes. Orion also lacks any support for other version control systems, so users of Subversion, Mercurial, or any other VCSes are out of luck for the time being.
Orion going forward
The next milestone for Orion is planned for June 3rd. This release should simplify server configuration, move to Dojo 1.6, and provide extension points for content assist, keybindings, and working with different editors. Orion is already attracting some interest from Mozilla, with an eye towards using the Orion editor in the Mozilla codebase. From the looks of the Orion development list the project is fairly active in general.
For now, Orion is not a tool for serious development. It has the beginnings of a competent development environment, but it's not something that one would trust for real projects now, or likely in the next year. If you're hoping to use it to knock out your next web site, you had better have low expectations or be willing to work with relatively primitive tools. However, if the concept of a browser-based web development environment stirs your fancy, then the Orion project is open for contributions. It should be interesting to see how the project develops, and if (or when) the browser-based model overtakes desktop tools.
Brief items
Quotes of the week
How comes nobody in other OSes noticed ? Well, people probably did, and tweaked their allocators to "work", by using preferably the low address space, and having addresses that increase slowly, so that a lot of pointers are below 4GB, and a lot of pointer diffs are under 4GB.
This is yet another example of the patheticness that is modern software development. Instead of going headfront and fixing the actual problems, most systems cope out and just sweep the problem under the carpet, hoping no-one will notice.
PiTiVi 0.14 released
Version 0.14 of the PiTiVi video editor has been announced. New features include audio and video effects, previews in the import dialog, a "welcome dialog" to help new users get started, and more; see the release notes for more information.Python 2.5.6 released
Python 2.5.6 is out, for those who haven't moved on yet. "This is a source-only release that only includes security fixes. The last full bug-fix release of Python 2.5 was Python 2.5.4. Users are encouraged to upgrade to the latest release of Python 2.7 (which is 2.7.1 at this point). This release is most likely the final release of Python 2.5; under the current release policy, no security issues in Python 2.5 will be fixed after October, 2011."
Google open-sources WebRTC
Google has announced (in early May) the release of the WebRTC code which, it hopes, will help to jump-start the creation of a new generation of communication applications. "Until now, real time communications required the use of proprietary signal processing technology that was mostly delivered through plug-ins and client downloads. With WebRTC, we are open sourcing the voice and video engine technologies from our acquisition of GIPS, giving developers access to state of the art signal processing technology, under a royalty free BSD style license. This will allow developers to create voice and video chat applications via simple HTML and JavaScript APIs."
Newsletters and articles
Development newsletters from the last week
- Caml Weekly News (May 31)
- Mozilla Engineering Newsletter (June 1)
- PostgreSQL Weekly News (May 29)
- Python-URL! (May 26)
- Tahoe-LAFS Weekly News (May 28)
- Tcl-URL! (May 28)
Duffy: Version-controlled, automagical backup and file sharing system with Sparkleshare and Fedora
Máirín Duffy has put together a step-by-step tutorial on setting up Sparkleshare for remote file synchronization. "I've built a solution using Fedora and Sparkleshare - completely free and open source software - that over the past week has addressed all of these issues and has substantially improved the quality of my computing life. It backs my work files up to an internal corporate server and it backs my Fedora files up to a Fedora-maintained public server. I'm planning to configure it to back up some personal files to my Dreamhost account and some to my NAS at home."
Neary: Effective mentoring programs
Over on his blog, Dave Neary investigates mentoring programs, like Google Summer of Code and others, to see what works and what doesn't. In particular, he looks at why so few of those who are mentored end up as project contributors, and what can be done to change that. "Mentored tasks should be small, bite-sized, and allow the apprentice to succeed or fail fast. This has a number of advantages: The apprentice who won't stick around, or who will accomplish nothing, has not wasted a lot of your mentor's time. The apprentice who will stay around gets a quick win, gets his name in the ChangeLog, and gains assurance in his ability to contribute. And the quick feedback loop is incredibly rewarding for the mentor, who sees his apprentice attack new tasks and increase his productivity in short order."
Page editor: Jonathan Corbet
Next page:
Announcements>>