Changes

* it would make it easier to "sugarify" web apps (like gmail).<br />

* it would make it easier to "sugarify" web apps (like gmail).<br />

* there are a lot of developers that are familiar with HTML(5), CSS and JavaScript and it would be great to take advantage of their skills.<br />

* there are a lot of developers that are familiar with HTML(5), CSS and JavaScript and it would be great to take advantage of their skills.<br />

Integration of web applications with the desktop is a very useful (and popular) thing to do. Gears, AIR, Prism, HTML 5 and various combinations between them extend the browser with: persistent storage, accessing files, desktop icons, running in a separate window/process, programmatic drawing, etc.<br /><br />

Furthermore, integration of web applications with the desktop is a very useful (and popular) thing to do. Gears, AIR, Prism, HTML 5 and various combinations between them extend the browser with desktop-like abilities: persistent storage, accessing files, desktop icons, running in a separate window/process, etc.<br /><br />

There are two main strategies for implementing this:

There are two main strategies for implementing this:

# Running a standard site specific browser, as light as possible, that has a local webserver written in python (BaseHTTPServer should suffice) as homepage. It would use AJAX or a wrapper on top of that (like jsonrpc) to provide the bridge to python. Also, as much functionality as possible should be on the html+js side, to keep the toolkit easily hackable by web developers. This version would use Sugar APIs over the python-js bridge for storage, other filesystem access and integration. The biggest downside is that this process could not be automated. Some python code would have to be written.

# Running a standard browser, as light as possible, that point to a local BaseHTTPServer. It would use AJAX or a wrapper on top of that (like jsonrpc) to provide the bridge to python. Also, as much functionality as possible should be on the html+js side, to keep the toolkit easily hackable by web developers. The biggest downside is that this process could not be automated. Some python code would have to be written.

# Embed a browser runtime (preferably with hulahop) that has Gears and move over even more things to the html+js side. The activity would be completely standalone and would not depend on a web server anymore. xulrunner has the advantage of a full javascript-python bridge, PyXPCOM. Dbus access through pyxpcom or [http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#WebKit_.28JavaScriptCore.29_version_notes this].<br />

# In a small controller application, embed a browser runtime (with hulahop) that has Gears. The resulting activity would be completely standalone and would not depend on a web server anymore. xulrunner has the advantage of a full javascript-python bridge, PyXPCOM. Dbus access through pyxpcom or [http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#WebKit_.28JavaScriptCore.29_version_notes this].<br />

I will be focusing on the second stragety.<br />

I will be focusing on the second stragety.<br />

* 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.