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 small local webserver (SimpleHTTPServer). It would use AJAX or a wrapper on top of that (like jsonrpc) to provide the bridge to python. The biggest downside would be that the SSB would have to call the python backend for persistence and interaction with Sugar. Another problem would be that this process could not easily be automated. Some python code would have to be written for any semi-interesting application. It would also be harder for web developers to hack Webified itself.

# Running a standard browser, as light as possible, that points to a small local webserver (SimpleHTTPServer). It would use AJAX or a wrapper on top of that (like jsonrpc) to provide the bridge to python. The biggest downside would be that the SSB would have to call the python backend for persistence and interaction with Sugar. Another problem would be that this process could not easily be automated. Some python code would have to be written for any semi-interesting application. It would also be harder for web developers to hack Webified itself.

# In a small controller application, embed a browser runtime (with hulahop). 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 [http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#WebKit_.28JavaScriptCore.29_version_notes this bridge], pyxpcom, [https://www.socialtext.net/lukec/index.cgi?xocom XOCOM] or, in a worst case scenario, AJAX. It would be very similar to other efforts to bring web apps to the desktop and it could also provide better integration with Sugar.<br />Browse could be used as a base for the Webified SSB. A small utility (probably an extension to the Browse activity) would create activities out of websites.<br />

# In a small controller application, embed a browser runtime (with hulahop). 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 [http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#WebKit_.28JavaScriptCore.29_version_notes this bridge], [https://www.socialtext.net/lukec/index.cgi?xocom XOCOM], pyxpcom directly or, in a worst case scenario, AJAX. It would be very similar to other efforts to bring web apps to the desktop and it could also provide better integration with Sugar.<br />Browse could be used as a base for the Webified SSB. A small utility (probably an extension to the Browse activity) would create activities out of websites.<br />

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

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

I also had some contact with C# and Java and have been thoroughly disappointed by their general lack of expressiveness. I did one small schoolwork in C#, that dealt with a [http://dl.getdropbox.com/u/317039/csharp.zip database of students]. Recently, I did another small schoolwork in Java, dealing with a [http://dl.getdropbox.com/u/317039/cricket.zip cricket club]. After finishing each, I was amazed at how much of my code was just boilerplate or fighting the type system, code that I wouldn't have had to write in a more dynamic language.

I also had some contact with C# and Java and have been thoroughly disappointed by their general lack of expressiveness. I did one small schoolwork in C#, that dealt with a [http://dl.getdropbox.com/u/317039/csharp.zip database of students]. Recently, I did another small schoolwork in Java, dealing with a [http://dl.getdropbox.com/u/317039/cricket.zip cricket club]. After finishing each, I was amazed at how much of my code was just boilerplate or fighting the type system, code that I wouldn't have had to write in a more dynamic language.