Changes

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

# 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. Javascript 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. Gears would have to be installed as a plugin for xulrunner. 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, since Prism is designed for regular desktops. Porting Prism would be too much work, but there may be useful code in Prism, especially the webapp 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.

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