thefoundation

OneSocialWeb: more than Jabber for Apps

2010-04-30T14:00:21Z

Almost a month ago, the presentation of OneSocialWeb at the android developers conference droidcon.be was one of the most interesting talks there. Recently the XMPP-centric framework has gone open source.

Last year a group of fellow students and myself were tasked with creating an android applications to organize meetings spontaneously (think something like doodle, only mobile and more short term). At that time we were thinking about using XMPP for real time communication, but were hesitant because of the time this would cost us to implement. In the end we used a traditional REST-based web service rather than a peer-to-peer system. Luckily there already is an effort underway which is called OneSocialWeb, funded by the telco provider Vodafone. It allows people to work together on Java-objects using XMPP.

This means that all the work that has to do with XMPP protocol handling and conflict management will be handled by this abstraction layer, while we developers can focus on delivering useful application. You could use this for simple things like associating chat conversations with arbitrary objects in your application. You could also try to model your entire application domain around this collaboration: In his presentation at droidcon Laurent Eschenauer demonstrated this using a collaborative shopping list where each participant could check off items, notifying the others immediately.

The Android platform with its services-model might really help in getting this concept to work, as XMPP protocol handling could be handled by one central service, dispatching updates to any interested Activities. This could well become the bidirectional, decentralized alternative to Apple’s Mobile Push service.

It appears I was wrong

2009-04-08T23:18:11Z

Yesterday, Google announced the availability of Java as the new programming language for the App Engine, refuting my guess from last year that it might be JavaScript — though of course, not entirely.

If you take the demand of the users into account, Java is of course the right choice as the next language. It might just alienate lots of Java-Developers if a niche language of the server zoo such as JavaScript was to emerge first. Additionally, Java is one Step short of full (albeit sandboxed) JVM support.

To allow for sandboxing, Google wraps some of its own API's into Java SE or JSR–standardized services such as javax.mail and java.net.URL. Also, there is a white-list currently containing 1323 of the 3700+ Java SE 6 classes. Most of the classes that are not available are from the Swing and AWT suites which a web developer will not need anyway. Instead, Google provides the homebrewn GWT.

Thanks to the free and open source Rhino JavaScript Interpreter written in Java, server side JavaScript on the App Engine is rather easy to achieve now. I guess I might have to check it out and report back about it later, so I just signed up for the Java technology preview on my App Engine account.

There are some videos from the Google Campfire event over at Youtube. Most of the time they are rather interesting, plus Kevin Gibbs does a pretty decent imitation of Steve Jobs during the presentation (voluntary or not).

Google Street View car spotted in Cologne

2008-10-18T22:50:00Z

I recently saw a strange car standing outside my house. I'm pretty sure it's the Google Street View car taking photos of Cologne! I managed to take some pictures...

I'm sorry for the bad image quality but I only had my mobile on me and the camera is pretty bad...
There is this tripod construction on top of the car roof where presumably the camera rig is mounted on. I wonder how fast the car can go without creating too much motion blur...well, I certainly don't want to be the guy who has to deal with all the photos they take day by day ;-)

Google Street View Car in Cologne

Is JavaScript The Next App Engine Language?

2008-09-21T04:00:28Z

As the language of the browser, JavaScript has become a kind of common denominator among web programmers. On the server it is rare compared to Java, PHP, Ruby or Python. Could this change, since Google has built an implementation of JS and an affordable yet scalable web application infrastructure?

Scripting Language of The Open Web

JavaScript was created as a scripting language for the Netscape 2.0 browser. Other than its namesake Java, it has remained in the browser since then. Web Developers know this language because they have to use it, no matter if they like it. Throughout the late 90s and well into this decade, JavaScript was mostly regarded as a toy language for silly effects and simple form checks. Due to the more recent experience with Ajax applications and the resulting thorough coverage in technical literature, the users of JavaScript have become more professional.

The Server Domain

The development on the server side has — with some notable exceptions — ignored the language JavaScript for many years. Perl was a dominant language in the early days. Then, PHP gained momentum in the fast growing developer community during the internet bubble due to its gentle learning curve, the simple integration with MySQL and the overwhelming availability of inexpensive shared hosting. You could say that in its ubiquity, PHP has mimicked JavaScript, only on the server.
Other languages and tool chains have gained momentum since then, most notably Ruby, Java and Python. They are not as affordable as PHP (except Python on the App Engine), and seem to be used mostly because of their modern MVC frameworks.

Why JavaScript Is Not Popular on The Server

JavaScript has some fundamental weaknesses that have inhibited its inception as a server side programming language:

JavaScript, — or rather ECMAScript — has no real standard library, it is just a language. There are no tools for file or process manipulation. There are no database bindings and there is no shared memory. There is no way to open a socket.
In the past, JavaScript Interpreters have not been known for their performance. Anyone who has seen the message A script on this page may cause Firefox to run slow. would think twice before writing an application in JavaScript.

The Helma framework tries to address the first issue by using the Rhino Interpreter, making the Java SDK available to the JavaScript programmer. The second issue is at least partially resolved as some performance intensive tasks are moved to Java. In Java 6, Rhino is even bundled with Java. Nevertheless Helma and similar integration efforts are not very popular, compared to Rails or Struts. A reason for this might be that Java for the web (the enterprise edition) is a very serious business, while the perception of JavaScript has long been ...well, the opposite of serious. The two cultures do not seem to mix well yet, as good as the technologies might blend.

Why The App Engine Loves JavaScript

When Guido van Rossum adopted Python for the Google App Engine, he had to remove lots of features because they would not work with the sandboxed, replicating environment which is the App Engine. It turns out that the limitations of JavaScript really make it an ideal candidate for the App Engine.

JavaScript is just a language: It cannot create sockets, files or processes. App Engine does not allow for that anyway, so this is a plus!
The language is easily sandboxed. Web Browsers have to do this all the time. This is ideal for a shared hosting environment.
It has a no database bindings included, but a natural serialization format, JSON. This is great for the Google Data Store, because it stores objects, not table rows.
Recently, JavaScript Interpreters (or, lets say JavaScript Machines) have become fast. There is V8 and it is fast.

It is known (at least since Guido van Rossums talk at DjangoCon 2008) that Google plans to adopt more languages for the app engine. Also, there are four primary languages that Google uses for development: Python, Java, C++ and JavaScript. Python is already available. Java is a good candidate for the App Engine, but it is not exactly lightweight certainly not shared nothing. C++ is probably the opposite of any sandboxable language.

In combination with a template engine, a free offer on the App Engine might give the already ubiquitous JavaScript language a final boost. The prospect of one language from model definition to client side computation is certainly compelling!

To encourage further speculations: With Google's V8 machine comes an embedding, process.cc, that contains code necessary to extend a hypothetical HTTP request processing application - which could be part of a web server, for example (...) (V8 Documentation).