158
edits
Changes
mLine 32:
Line 32: − + − + − +
no edit summary
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 />
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 />
There are two main strategies for implementing this:
There are two main strategies for implementing this:
# 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.
# Running a standard browser, as light as possible, that points 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 (at least not in a nice way). Some python code would have to be written.
# 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 />
# 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. Javascript 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 />
* 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. Porting Prism to Sugar would be wasteful, since Sugar already has hulahop which is as stripped down a firefox as it gets. Building on that should be easier.
# 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. Porting Prism to Sugar would be wasteful, since Sugar already has hulahop which is as stripped down a firefox as it gets. Building on that should be easier.
# 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.
# 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.
* 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.