But even the development just for the client-side is cumbersome. A typical approach is to use an editor to edit the client code and then run it in the browser, where the browser debugger is used to inspect the behavior. If a problem is encountered the code has to be adjusted in the editor, refreshed in the browser and can than be debugged again. Although some debugger also provide live-edit, this functionality only provides temporary edit of code that only lives as long as the web page is managed in the browser. Paul Rouget describes this problem in a recent post , where he points out possible alternatives to the mentioned development process, which he appropriately names editor-browser-devtools workflow. The Firefox devtools are developing into a direction, where they can be integrated with other development tools, hence providing tool-developers with the possibility to break the cumbersome workflow.
Eclipse Orion advocates the approach “Tools for the web, on the web”. As it is, it already stands out as a great Online-IDE. An important tool which is still missing  and not planned for the near future  is a runtime debugger. The debugger is extensively used by web developers. An integration into Eclipse Orion would enhance development experience. There would be no more need to
- switch between different tools for the client and server side development
- and no need to switch between browser and devtools to debug and edit the client-side code.
Goal for Google Summer of Code 2013
- Getting involved with the open source community
- Understand development process for Eclipse Orion
- Learn about plug-in mechanism and how to extend Orion
- Learn about UI design and user experience
- Implement a browser-based debugger for at least one client- and one server-side technology.
The implemented debugger should have basic debugger functionalities, source editing functionality and support for one client- and one server-side technology.
Following basic functionalities should be implemented
- step-by-step execution
- expression evaluation (chrome offers evaluation at runtime and when the debugger is paused).
- visualization of and navigation through the callstack
This functionalities should be realizable for a client and a server-side connection.
The implementation might be very simplisitic if it turns out, that not enough time is available. For example the expression evaluation might turn out to be nothing more than an input field, as opposed to the widespread behavior that an element is evaluated when the mouse is moved over it.
The next important feature would be source editing, by which I mean, that code execution can be followed and edited persistently in the same editor view. This would break the necessity to switch between editor and browser debugger, when one wants to edit code or debug the code execution.
Supported client- and server-side technology
While working on the proof-of-concept implementation for my master’s thesis, I made myself familiar with web development in general and the chrome extension mechanism. But I am not yet proficient with those technologies. Before that I have been mostly involved in Java-based projects. The last one being Tigerseye, an Eclipse plugin, which is hosted on Github .
April: Getting familiar with Orion, provide some simple bug-fixes or enhancements.
May: I collected enough knowledge about Orion and the debugger I want to support, to be able to write a timeline for my project.
June through September: To be worked out.
The implementation months actually clash with the time I would have to prepare for exams in Germany. But I only have three exams left, worth a third of a semester. So I should be able start working on the project half-time from April through June and full-time during the coding season. Apart from a few days off to get fit for my exams, which shouldn’t be more than two weeks all together.