SPDY could gain acceptence very quickly - with some product innovation

Google have announced some early findings about their research into a faster protocol to reduce latency times due to good old fashioned HTTP. HTTP was designed as a really simple protocol to delivery (primarily) text content over the Internet and thus was born the Web.

One of the problems with HTTP is that it only really allows a single request to be serviced at any one time. The reason this doesn't APPEAR to be the case is because modern browsers create multiple connection threads that connect independently to the server and it gives the appearance of things downloading in parallel. It's a neat hack and works because we have good network speeds and mast processors to manage all this multi-tasking. Go back to a Pentium II with Netscape 2 and you'll watch the glacial procession of elements loading in from the top and goes down the page.

The Google project page talks a lot about why HTTP pipelining doesn't work and some of the technical architecture behind SPDY which I won't cover here other than to say that it's great we are seeing this type of innovation at the protocol level. What's most interesting for me however is how we get it in production.

There is a lot of nay-saying going on around this suggesting that because of the size of the Web you'll never get people to shift to a new protocol HTTP:// won, let's all leave it at that because there are too many web servers and web browsers to convert. This is what I want to address in this post.

Yes - there are fair too many legacy browsers to deal with to make this transition happen. Look how many IE 6 browsers are still in use, but we'd also have to shift all the Mozilla users, Chrome users (easy because of forced update) and Safari users as well. Not to mention all those pesky mobile devices that are springing up.

Dealing with the web servers is a much more straightforward issue. There really aren't that many in the scheme of things. Indeed much of our existing infrastructure runs multiple servers, Apache alongside a lightweight server like nginx and this is increasingly common.

As such there's nothing stopping me dropping in a SPDY server alongside my existing infrastructure for those users that can directly access it (Chrome 4, Firefox 5, Safari 6 and IE 10 for example).

But let's not stop there. A network admin could create a software appliance at the Firewall or Internet Gateway level for the corporate network that took HTTP requests, turns them into SPDY requests and then proxies these back. Now I have doubly fast Internet connectivity without upgrading my connection. For the price of a box that is well worth it.

For home users we could do the same thing. This protocol is software - it runs on TOP of TCP so because of that a Firmware upgrade of your average Netgear or Linksys home router could get you the same benefits as those above. ISPs could force this remotely on certain systems (Cable for example) or provide info on how to do it such as through a web, phone or personal service.

So for all the nay-sayers out there - this is a MASSIVE opportunity to speed up the web and people need to think outside the browser sometimes. QoS was delivered at the router level based on intelligent packet analysis - that speeds up network traffic massively but it's a software change not a hardware one.

I don't think it will be long until we see Netgear and Linsys start promoting this like they did with the WiFi standards and force adoption because it makes a great marketing case to do so.

I'll be trying this out at the rawest state to see if we can make it work and if I can, watch how fast our servers and network gateway get upgraded before I embark on upgrading client machines.

AdMob purchase by google paves way for interesting developer funding

It's just been announced that Google is set to buy AdMob for $750M in an all-stock deal. This is the third biggest purchase Google has ever made (the only two bigger are YouTube and DoubleClick).

AdMob started in 2006 so they have capitalised very well for a 3 year old business. Indeed they've been cash positive for a while now so this is a great acquisition by Google. The full gory details of the deal can be found here and a press site by google here

We know this is all aligned to Google's interest and in particular their big appetite presently for anything Mobile. However this also opens up some enormous opportunities for developers.

This acquisition brings with it some great opportunities for in-application display advertising that is delivered contextually but also based on Google AdWords auctioning technology. Along side this I can then use the same advertising account to drive ads on my mobile website that compliments my application and then use standard ads on my main website that provides additional information / community support etc.

All of a sudden a possible revenue opportunity opens up that was kind of there previously but wasn't very smart. Over the last 18 months in particular we've been watching the rise of free-ad-supported applications as well as paid-no-ad versions of the same application. I would expect to see a lot more of the ad-supported apps once this deal goes through.

The reason for this is twofold:

1. As a developer I can manage all of my advertising spaces with one vendor. I don't really want to have to deal with all these businesses I just want to get some beer money for my app that I'm spending my non-work hours producing.

2. With contextual ad serving, I can make certain elements of data within the application available and use that to generate calls to the Ad Server - much the same way AdWords works with a web page or in Gmail. This means the ads that are served will be more relevant to the content which should lead to higher Click Through which then leads to potentially more revenue for me (see note above about beer money)

This makes a lot of sense for an advertiser as well. Certain applications have huge amounts of uptake - twitterific on iPhone or Twidroid on Android for example. Imagine having contextual ads served based on the content of your twitter stream. Twitter might resist it but it could make some serious cash for the app developers.

Overall I think this will really blow the top of mobile advertising. Advertisers who have been a little shy in the mobile space will be comforted by the fact it's Google doing it. App and mobile site developers stand to gain some good funding from it and it be relevant for their audiences and as the world goes increasingly smartphone mobile mad over the next 18 months this will be worth serious $Billions in the next 5 years or so.

Cross posted to Citrus Agency Blog

Crown Oaks Day Racing Challenge

Last night I was writing code to play around with an idea I had rather than studying the Form Guide. See today I am off to the races (Crown Oaks day at Flemington) with some clients - hence why I should have been studying the form guide and not playing around with Erlang.

So I've decided to try an experiment:

Can the wisdom of the Twitter crowd outperform both blind luck and the bookies favourites with regards to return on bets during the racing.

Now we all know blind luck should lose. Betting on a winner at random is probably not going to get a single hit but against the favourite should prove interesting.

What interests me most is that betting on a race is actually contributing to an Information Market. Now theoretically information is held by all the various agents (people betting) and each one doesn't have a full picture but together the market becomes efficient and pushes down the odds of certain horses winning and then having long shots.

In smaller races where you have not so many people betting this works and either the favourite or a horse will relatively low odds will win. At large race meetings this doesn't work because a lot of people bet randomly (based on name, birthday number etc) and because of this it creates a lot of noise in the market so it breaks down.

So here's the challenge.

I'll start this from Race 3 at Crown Oaks Day today.

Each of the races is displayed below with a link to the field list. I'll be making a bet based on complete randomness (random number of the horse) and following the bookies' favourite. I'll then take the majority from messages to my twitter account (@ajfisher) for that race and place a bet following that. Simply send me a tweet "@ajfisher Race: NUMBER Horse: Name or Number"

Race 3
Race 4
race 5
Race 6
Race 7

Also you can use the tag #crowd-oaks if you want.

So can a smaller crowd provide more wisdom and outperform the bookies and complete blind luck on a big race day. Let's find out. It'll be fun either way.