Skip to content

GWT Server Communication Strategies

I have been doing a fair bit of GWT wrangling lately, but noticed my blog didn’t reflect that.  I thought I’d do a broad survey of GWT server communication strategies.  By server communication, I mean the ability to transfer data to or from or to and from a server.

Since GWT is, at the end, just javascript, these methods that work, work for any javascript code (those that don’t work may fail due to GWT strictures).  But I’ll be looking at them with a particular GWT focus.  I created a sample Eclipse project that shows all of these methods (except for GWT-RPC, since that is so well documented and requires a java server).  I encourage you to download it and toy around with each of these methods.  I used GWT 1.5.3 on Windows, and tested the code in both in the hosted browser and my normal browser (FireFox 3).

For the anxious and impatient, here’s a quick table overview.

Method To server From server Cross domain Payload length Notes
HTTP request yes yes no unlimited (post) developer responsible for making sense of data
GWTRPC yes yes no unlimited (post) only works with java server on the backend
JSON yes yes yes limited by URL length (2048) hard to determine when data is loaded
JSONP yes yes yes limited by URL length (2048)
Form yes yes/no yes unlimited payload no server response available if posting cross domain
Iframe yes yes no limited by URL length cross domain fails

HTTP requests are the simplest way to retrieve data from the server.  The data retrieved can be anything (text, HTML, JSON, XML, some other data format, binary data, etc), but you as a developer are responsible for taking that data and turning it into something your program can use.  Also, since HTTP requests use XMLHttpRequest under the hood, you are limited to the same hostname that your GWT code was served from.  This is the default setting for most browsers (the so called Same Origin Policy)–I did notice that the GWT hosted browser does let you pull HTTP Requests from a different domain, after a warning.  FF3 does not allow the cross domain request at all–it fails without an error message.  Data transmission is two way.  The GWT documentation provides sample code.

GWT-RPC is the method that is given the most attention in the GWT docs.  GWT-RPC provides plumbing to marshal and unmarshal java java objects marked with the Serializable or IsSerializable interfaces.  The data object can’t contain any fields that GWT doesn’t know how to translate, like URI.  GWT-RPC is currently built on XMLHttpRequest and is subject to all of its benefits and limitations.  Data transmission is two way.  The GWT documentation contains sample code.

JSON is a data interchange format that encodes data in a way that can be executed by javascript compilers.  It looks something like this:

var myvar = {"msg":"plain json"};

GWT can use JSON to pull data from remote servers.  Data can be transmitted both ways, but in GWT it is hard to know when the data has been returned from the remote server.  (Also, there are some security implications.  Read the article linked to above.)  You can poll via a Timer to see if a variable has been created. (This is tedious, but may be the best option when the server JSON output is not under your control.)  The closely related JSONP method uses a function instead of a javascript variable, and removes the need for any Timer.

JSONP takes JSON the next step farther and adds a callback function into the mix.  That way, when the remote data has been loaded, a javascript callback function will be executed.  It looks something like this:

my_fcn({"msg":"plain jsonp"});

When the script is loaded, the json is executed, and my_fcn will be executed as well.  I’ve used this quite successfully to make GWT widgets pull data across domains.  This excellent article has an almost complete implementation.  The only thing missing is removing the scrip tag when the callback function is called.  My code just associates a uniqueId with every script element.  After the JSON is parsed, the element is removed.

private native void removeScript(String uniqueId) /*-{
var elem = window[uniqueId+"DOMELEM"];
if (elem != null) {

Form Submission is a method of server communication that really excited me, because I know that in HTMLland, you can do cross domain posts rather easily.  In theory, this means you don’t have to jump through the hoops of JSONP, and can have large amounts of data sent.  Alas, it was not to be.  You can post forms cross domain, but “The result html can be null as a result of submitting a form to a different domain.”  The data does get to the server, though.  If you are trying to get a large amount of data cross domain, this may be useful, but you’ll have to use some kind of polling with JSON or JSONP to determine that the server has handled that data in the way you expected it to.

IFrames were the original remote scripting solution and GWT supports them…kinda.  I was surprised to learn that a cross domain iframe failed in the hosted browser with a security exception.  It also fails in FF3 with the exception: “Permission denied to get property Window.document”.

I hope this tour of GWT server access methods and code is useful to you.

[tags]GWT, GWT remote communication, how can I get my widget the data it needs[/tags]

Need To Identify Your Motherboard? Try CPUID

I was trying to identify a motherboard for relatives so that I could buy them some memory for the holidays.  (What can I say, I’m a romantic!)

I wasn’t able to find it via the Windows Device Manager, but luckily, Google turned up the answer: CPU-Z.  It’s a freeware program that not only tells you any number of useful bits of information about your computer (like the motherboard model and manufacturer), but also will export it to an HTML file suitable for emailing.

This is not information I need every day, but when I did, CPU-Z came through.  Thanks, folks!

[tags]motherboard identification, memory, hardware[/tags]

Why aren’t you using Google Website Optimizer?

I’ve been using Google Website Optimizer (GWO) in one form or another for over a year now, and I am quite impressed.  I wish everyone would take a look at this technology.

The short version of this post is: if you have a website that gets some traffic, and actions that you want a user to take, such as buying something, you should use GWO.


Let’s talk about GWO a bit more for everyone who didn’t leave after the executive summary.

First, what is GWO? 

It is a free add in to your website that lets you test the effect of content changes on desired user actions.  For example, you can test the impact of different headlines (‘Sign up for more information’ or ‘Free Newsletter!’, etc) on a newsletter signup page to see how it affects how many users sign up.

I could try to write about it more, but instead, here’s a video that explains how to set up a test; you can watch the first 45 seconds to get a good overview of what GWO helps you test, but the whole video is worth viewing.

It’s important to note that GWO is javascript based (as opposed to some other tools like SiteSpect, which uses DNS proxying, according to a conversation I had with someone who worked there).  There are other tools out there which may be better fits for your needs.

Now, how should GWO be used? 

This tool should be used to optimize a specific action that you want the user to take, and that action should be something on the web.  Examples of actions that GWO can help optimize include:

  • sign up for a newsletter
  • visit a specific page
  • order something
  • give you their contact info
  • watch a video
  • download a file

GWO is capable of handling more complicated scenarios too.  You can, with a bit of javascript hackery, test button click conversions, or any other javascript event.  I’ve worked on systems that tested various form elements (requiring different fields to register, for example).  The requirement for that is a flexible back end, and a javascript front end that can handle re-filling form elements on error.

Next, why would you avoid GWO?  There are a number of scenarios where using this tool just doesn’t make sense.

No actions that you want the user to take on the web

This is the biggest set of sites for which GWO does not make sense, and my blog falls into it.  My end goal is really to talk to someone, on the phone or over coffee, to ascertain whether or not I can help them with my services.  That’s a hard conversion to track.  If you really want to get people talking on the phone, that is a conversion that GWO doesn’t help track either (though it’s possible you could do something with VOIP or different phone numbers and cobble some kind of conversion tracking together).

That’s not to say that sites in this category can’t use GWO.  For instance, I wrote an article long ago about a java technology called JAAS, and it’s still pretty popular.  I’ve been doing some testing on that page to try to drive traffic to this blog, where a big chunk of my current writing is happening.  I was able to increase conversion about 2.5 times (granted, from a small base–0.7% to 1.73%).  I could definitely try to do some optimizations around ad placement or contact calls to action.  The main reason I haven’t is that I still believe my best chance at conversion is referral or word of mouth, not better text on a website.

Javascript free site

If you need a javascript free site, or focus on users who don’t have javascript capabilities (those who use screen readers, for example) or browsers that don’t support javascript, then GWO isn’t a good fit.  That doesn’t mean you should give up on optimization, it just means that GWO isn’t the solution.

Google trust issues

For providing this valuable service, Google could get a look at a lot of interesting data including how many websites optimize, what site admins are tracking, and what URLs those admins consider important.  I have no idea what Google actually does with the data–the company may not track the data at all.  I did a bit of looking on the GWO forum, but didn’t find anything useful.  However, if you don’t want Google having access to this data, then you shouldn’t use GWO.  I don’t use Google Analytics for this very reason.

Speed is essential

Since this is a javascript download, it will affect page load time.  From Firebug, I see that it is a small download (7KB total, over 3 requests–for the test page).  This is not significant, but if you’re aiming for the fastest website, or you’re aiming at users on a slow connection, you might steer away from GWO.

Not enough traffic to your site

If you don’t have much traffic, your effort will be better spent driving more people to your website.  Whether you use search engine optimization, TV advertising, pay per click campaigns, or my favorite, regularly posted organic content, traffic is a prerequisite to using GWO effectively.  How much traffic?  Well, I was able to get conclusive results in my JAAS experiment with 3466 views and 48 conversions in just about 3 months.  That’s about 40 views a day.  I was not testing a ton of variations in my content (only 3).

Your site doesn’t let you put custom javascript on pages

This is the case with blogs ( doesn’t allow any custom javascript, due to WordPressMU’s architecture), and I’m sure is common among other ‘build a website easily’ systems.  Not much to say about this, other than that if you’re really using the web as a channel, and not just an online brochure, it might be worth moving to a more flexible site.

Not enough time

I don’t believe this is a valid excuse–spend 7 minutes and watch the video; I believe you’ll see that this is worth a bit of investigating if the above scenarios don’t apply to you.

I can’t think of any other reasons not to use GWO.  Feel free to leave a comment if you feel I missed something.

What are your next steps?

Well, if I’ve convinced you that GWO is worth looking at, you might want to do a bit of further research. Here’s the website optimizer homepage.  Here’s the official GWO blog.  Here’s a great article full of tips for GWO.  There’s a book called Always Be Testing that seems pretty well received that you might want to check out.  I have not read it.

Disclaimer: I’d love to help you out with this (if interested, contact me), but firmly believe that almost anyone can take 30-45 minutes and implement this on their website.  I think GWO is great, cool, useful technology and want to see it used more to make the web a better place.

Open Source Ad Server Roundup

I found this vlog post about a social network building their own advertising infrastructure to be interesting.  Basically, Dogster founder Ted Rheingold (whose lapdog gives him a Bond-villian-like presence during the interview) argues that building your own ad pipeline is harder than using an ad network, but is far more profitable and sustainable.  Ad networks are easy to slap in and give a startup instant revenue, but automated content targeting leaves something to be desired.  In addition, there’s no relationship built between the content purveyor and the advertiser, which leaves the content purveyor more vulnerable to advertising cutbacks.  Advertising salespeople are the easiest to hire, and the easiest to fire, as they should pay for themselves.  (As an aside, here’s an interesting article by Jakob Nielsen talking about how “paid search confiscates too much of a website’s value.”)

I passed it along to a friend who is building a directory site around local Colorado farmers and food and he mentioned some interest in it.  On my own, I took a look around to see what was available for self managed website advertising, and was surpised at the paucity of good open source ad serving software out there.  After all, advertising is one of the great business models (of the web, and of all time); I expected to see a bit more code out there.  But perhaps ad network software isn’t anyone’s itch.  Or maybe there’s no demand for it–sites are either small enough to use Adsense, or they are big enough to pay for a commercial ad server.  Regardless, here’s what I found:

There were a number of projects on source forge that seemed appropriate, but nothing that was actively maintained and useful (lots of projects started in 2001, and dormant).  Adsapient seemed the most useful, but they say on their website: “AdSapient Ad Server is an open source ad server that can be used as a platform for building your own ad serving technology. We recommend using it for educational purposes though.”  Not exactly a ringing endorsement.  Update, 4/27/2009: Someone who worked on Adsapient has started a new ad server.  More information below.

For some reason, this didn’t show up on my search of Sourceforge, but OASIS is definitely an ad serving and management solution.  Last release was 2007.
There is a company that offers hosted OASIS and OpenX ad serving solutions, but they’re rather pricey.  Another (closed source) option is Google’s ad management solution.

The best solution I could find was OpenX.  They have a demo site that works, they are continuing development as you read this, they have a free hosted solution good for up to 25 million impressions a month, and at that time, you can choose to either pay them a monthly fee, or download, install and configure the software and run the ad server on your own box.

Now, I haven’t spent enough time with the OpenX UI to know if there are dealbreakers in there, but based on pricing, ongoing development effort and freedom, I would definitely recommend OpenX.  Here’s an interesting discussion comparing the hosted OpenX solution and Google Ad Manager.

[tags]google ad manager,openx, oasis, ad serving, hosted ad solutions[/tags]