Changes

* Why not use existing solutions like Mozilla Prism or Titanium?

* Why not use existing solutions like Mozilla Prism or Titanium?

# Prism. It's just a stripped-down firefox. To make it useful, at least Gears would have to be installed and there would still remain the issue of integration, since Prism is designed for regular desktops. Building on hulahop and the existing Browse activity would yield better integration. There may still be useful code in Prism, like the SSB creation utility.  

# Prism. It's just a stripped-down firefox. To make it useful, at least Gears would have to be installed and there would still remain the issue of integration, since Prism is designed for regular desktops. Building on hulahop and the existing Browse activity would yield better integration. There may still be useful code in Prism, like the SSB creation utility.  

# Titanium. Titanium is more interesting, as it already is an SDK for creating desktop applications with web technologies. It's only real technical disadvantage is introducing a new dependency (webkit) in Sugar. However, it's [http://titanium-js.appspot.com/Core/Titanium design] is largely incompatible with Sugar, as it focuses on traditional desktops. Refactoring all that to fit into Sugar would be too much work.<br /> However, since webkit may very well be faster and use less memory, I will investigate an alternative backend for hulahop based on webkit.

# Titanium. Titanium is more interesting, as it already is an SDK for creating desktop applications with web technologies. It's only real technical disadvantage is introducing a new dependency (webkit) in Sugar. However, it's [http://titanium-js.appspot.com/Core/Titanium design] is largely incompatible with Sugar, as it focuses on traditional desktops. Refactoring all that to fit into Sugar would be too much work.<br /> However, since webkit may very well be faster and use less memory, I will investigate an alternative backend for hulahop based on [http://code.google.com/p/pywebkitgtk/ pywebkitgtk].

* What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.

* What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.