gmail

Since last year, April the 1st, Google is regularly releasing interesting new products and services. Last year they kicked off with gmail, a free email service with some interesting technical characteristics.

It basically shook up the whole web design community by demonstrating that html+javascript+xmlrpc (a.k.a. AJAX) allows for some nice, interactive applications. It and similar web applications that since have been developed basically show how the next generation of webapplications can and should work.

So gmail uses xmlrpc to implement some interesting things using ajax:

  • Spelling checker
  • Address completion
  • Auto save of new messages
  • Fetching content without refreshing the page

Plus they allow their users to store gigabytes worth of email. The entire collection of email I’ve collected and kept over the past ten years is less than that!

Recently I’ve abandoned thunderbird, which is a nice mail client, and started using gmail for all my things. I find it works very well and includes a number of features that I have not seen elsewhere so far. The most important feature for me is that it groups related messages (and replies) into conversations on one webpage. This allows you to keep track of long running conversations easily and is also very convenient for mailinglists.

Another thing that I like is that the mail sits on a server. It doesn’t matter where I am, I can always access my full mail archive. I’ve been messing with pop based accounts for years. Inevitably you answer some important mail via some webbased account while traveling. Then you need to forward the reply to yourself for archiving, which is error prone and generally forgotten.

Pojo + ajax = KISS

Lately there has been a lot of fuss about POJOs and AJAX. POJOs (plain old java objects) are the answer to adding multiple layers of complexity just to store some simple data in a database. Some developers discovered that “hey I don’t have to bend over backwards if I just do an insert query here instead of writing dozens of deployment descriptors, ejbs and what not” and called this POJO.
Ajax on the other hand is just freeform httprequests with minimal restrictions: post something & parse the string that comes back. As such it is actually a very good drop in replacement for almost all applications of soap. Both are actually applications of the plain old KISS principle: don’t add complexity where you don’t need it. Complexity increases maintenance cost and it is only justified in a tradeoff where you gain something you need (e.g. flexibility). Soap and EJBs are examples of technologies that typically don’t justify the added complexity.

While soap can be used for more advanced stuff than remote procedures, it rarely is used in any other way than yet another remote procedure protocol. Soap calls have a number of disadvantages including performance, scalability, poor interoperability despite piles of specifications and complexity. Soap is actually not really suitable for RPC because of the high latency which forces you into a very coarse grained usage pattern (few calls with many parameters instead of many calls with few parameters). If each soap call takes 150ms, you can’t afford more than two or three in a single transaction. So soap is really optimized towards posting a really complicated message and receiving something equally complicated back. If instead you want to do something simple like “doFoo with parameter X and Y and tell me if it worked” it is much more efficient to post a small message using http to a server that understands this message and returns “true” or “false”. That’s what AJAX is about. Http posts can do roundtrips in 20ms on a good network. So you can afford to do lots of them, e.g. from a javascript running inside a browser.

That’s actually all AJAX is about because there’s no such thing as a specification which tells you how to construct an AJAX message. Neither is there a POJO specification which tells you how to construct simple java objects to store simple data. POJOs and AJAX are something you are already supposed to have: common sense. Keep It Simple Stupid.