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
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.
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:
So all we are suggesting is that you move the remaining software
development activities to the browser, too. [...]
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
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
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 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.
Comments (none posted)
Code that assumes that ASCII is good enough for writing English
properly is stupid, shortsighted, illiterate, broken, evil, and
wrong. Off with their heads! If that seems too extreme, we can
compromise: henceforth they may type only with their big toe from
one foot (the rest still be ducktaped).
Unfortunately, there is a problem with Free Software developers,
firstly - they often don't wear suits, and (get this) some have
beards: which just shows you the kind of schmucks they are. But
worse - they have odd, meritocratic, collaborative decision making
processes, that don't come up with suitably corporate answers.
Not surprisingly, a lot of software that claims to be 64 bits-ready
isn't. This touches all web navigators, most jit engines, and
probably lots more of software (our ports tree version of gnu-grep,
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
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.
-- Marc Espie
Comments (none posted)
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
for more information.
Comments (none posted)
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.
Full Story (comments: none)
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
Comments (21 posted)
Newsletters and articles
Comments (none posted)
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.
Comments (1 posted)
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.
Comments (3 posted)
Page editor: Jonathan Corbet
Next page: Announcements>>