Javascript, Rebranded

I’m listening to Steve Yegge’s talk on branding from last years OSCON.

He talks about how languages are branded, e.g. “Java” is enterprise. One of his main points is that brands are “const identifiers”, i.e. it takes an entire generation to change brand perception, so it’s often more effective to simply re-brand. e.g. GTE had a poor brand, so they tried a self-deprecating ad campaign, which backfired, and subsequently re-branded to Verizon.

He then mentions Javascript has a branding problem, because it represents “browser” and “toy language” and “damnit, I gotta learn Javascript” and it’s the language no-one wants to use. He also notes the name itself isn’t great either, nor the rhino imagery. (I’m not sure why Steve assumed many programmers would associate Javascript with rhinos; the Rhino product and O’Reilly cover weren’t really promiment enough to do that; rhino ain’t camel!). I don’t agree with this premise. Javascript has actually become at least somewhat cool in certain communities, pretty quickly. Not the obvious ones like Rails and general web 2.0 fanboys/girls, but also PHP and Perl folks who would have previously been uninterested in it.

Anyway, he leaves the issue open and implies Javascript needs to be re-branded. But isn’t the point here that Javascript, for most and intents and purposes, already has been re-branded, like sometime around February, 18, 2005? It now shares its name with that of a domestic cleaning product, Dutch football team, and Greek God. For most people, Javascript became cool and worthy the day Ajax was coined; and Ajax encapsulates most of what is meant by Javascript. Of course, the two aren’t strictly synonymous, but when you set out to learn Ajax, you’re predominately learning Javascript. Go read a day or two of Ajaxian news and the vast majority will involve Javascript at some level.

Javascript has already been rebranded. In fact, I’d go so far as to say “Ajax” was one of the most successful rebrandings in software history.

A Video Sharing Website based on Web 2.0 Patterns

We’ve done a little group exercise at the TOOLS web 2.0 patterns workshop. Designing a video website, with heavy emphasis on mashing up, e.g. show videos from youtube, grab recommendations from netflix, grab friend lists from Facebook, etc.

Here’s the full feature list (click for full image):

And the design:

We eventually identified features, at back end and front end, and listed similar sites where on might get inspiration for each feature. Interestingly, when you do this with web 2.0 sites, you end up realising you could actually implement the feature by actually using this service.

Dragos has transcribed the list we came up with (partly visible in the photo above):

Day 1: Design Exercise

Problems + Solutions (1) [MM - these were back-end features]
-Key-value store: Amazon Dynamo/S3, BigTable (Google)
-Streaming: Hulu, YouTube streaming (not Flash)
-Client time synchro service: NTP, MMORPG
-Social network integration services: Oauth, OpenID/Passport
-Mash-up engine: PopFly, Yahoo! pipes
-Monetization (social cash -> $, analytics, instrumentation): AdSense,, SiteMeter, Elance

Problems + Solutions (2) [MM - these were front-end features]
-Video: Vimeo,,
-Mood: Musicovery, Yahoo! IM,
-Friend states: Twitter
IM: Facebook/MySpace, Twitter, Shoutbox
-Recommendations: Tuneglue, Netflix, Facebook

Some Emerging Themes
-Taxonomy of social networks
-Social profile aggregation: InfoCard
-Integration of services transparent from user
(Tim O'Reilly’s innovation by assembly)
-Privacy (who sees what)
-Biggest pile wins
-Cooler than thou 

OpenSocial: A Beautiful Platform for Server-less Web Development

It’s belatedly dawned on me how OpenSocial makes a great server-less Ajax platform. When you create an OpenSocial gadget, you’re building a lil Ajax app that performs much coolness that would normally require a server, but doesn’t. Effectively, you’re delegating the duties of the gadget’s host environment. All you have to do is write a single XML file and host it somewhere. In fact Google Gadget Editor gives you an editor to write it in and a place to host it.

In fact, this is so good that if I was teaching someone Ajax in 60 minutes or less, I would consider getting them to write a gadget. It’s that simple. Previously, I might have got them to write a static HTML file, with embedded Javascript and CSS, but now they can do the same thing and benefit from server-side features too, features they never had to install. This is like getting the usual benefits of the DOM and the Javascript API, but with much more. You’re getting both a set of APIs, just like when you use JQuery or Prototype, but you’re also getting a server which many of those APIs rely on. So it’s a true platform.

By the way, I’m assuming you’re using XML content type, not URL. XML content type is the way forward, especially as we move to a Caja world. XML gadgets will get you the richest functionality. URL gadgets are only suitable for legacy concerns, and in some cases, accessibility.

So you’re using XML content type, which means the entirety of your Ajax app lives in one file. What does an OpenSocial platform provide to your little XML gadget spec?

  • Persistence. The most important thing is you can save application data. You can serialise any state you care to persist, and then store it as a hidden user preference. This is really neat. It means you can write a TODO gadget, for example, and ensure all the TODO tasks will be saved, but without having to store them on your own database and without having to build a persistence layer around it. And of course, the platform will (theoretically) provide the necessary security to ensure users only see their own tasks.
  • Preferences. You can easily let users customise your app via the preference API. For free, you get form fields to let users state their preferences, with drop-downs for enumerated types. And of course, the preferences are persisted without any effort on your part.
  • Content Fetching. It gets even better. On-Demand Javascript is often bigged up as the way to get data from third parties. But thanks to OpenSocial’s remote fetching APIs, it’s just as easy to grab content via the containers Cross-Domain Proxy. This means you can get any internet content and call any API, not just those specifically designed for cross-domain browser calls. There are also value-adds here, e.g. caching, scheduling periodic updates, converting feed data of any format into a consistent JSON structure.
  • Identity and Social Networking. Ah yes, the almighty “social” in OpenSocial. On the right platform, your server-less Ajax app can get info about the page owner and the page viewer, and their friends. Friends and social stuff and knowing whose page it is, that’s cool and all. But what’s really exciting here is much simpler than that – it’s simply IDENTITY. What matters most is: With a single API call, you get an ID for the guy viewing your gadget!!! You didn’t have to handle registration, password reminder links, etc. etc., and go through all the associated security questions around it. All the usual stuff you have to do if you want to know who’s using your application. It’s all *free* to you, gadget developer. (Downside is your company doesn’t “own the user”, so your gadget will never get you pina coladas on the beach at noon and an environmentally-conscious hybrid vehicle to sip frappachino grandès in.) With this user handle, you can also save a hashmap of information about the user, persisted by our friend the server.
  • Many other services. Each platform is free to provide any number of features beyond the required API; this is how platforms compete against each other in the OpenSocial world. “Feature” is actually the term used for a particular set of browser and server services, e.g. “dynamic height” – the ability for a gadget to update its height – is a standard OpenSocial feature. Notifications – the ability for gadgets to add little notes to the top which the user must manually clear – well, that’s a custom feature iGoogle provides but others don’t. So anyway, there are lots of these features and your gadgets get them for free. In most cases, they are just libraries which you could also get for free by using Scriptaculous or whatever…but still, with OpenSocial, it’s really, really, easy! No download or installation. (Although it must be said that with library CDNs like Google’s new effort, you can also use many Ajax libraries without installation too. The difference here is that at least some of these features are tied to server-side services as well.)

So, these days, OpenSocial may well be the easiest way for a newbie to learn Ajax, and for any developer to get an Ajax app up and running. I actually think we need more tools and services to allow standard Ajax apps – not gadgets – to get up and running fast too. After all, the UI in OpenSocial is based on a widget/gadget model, and this is a mini web app running on a bigger page. Nowadays, we have canvas gadgets, which are bigger, but still not so big and run inside another web page. What if you took the same cloudish platform principles and applied it to a big old Ajax app, occupying the entire page and with its own URL (though probably coming from the platform’s domain). You can sort of do that already by looking at the content of the gadget iframe, but it’s not designed for that purpose…and if it was, you could do some interesting stuff.

For instance, I envisage a simple-to-use cloud storage system based around principles of Persevere and CouchDB, and for limited use, it could even allow anonymous access. I’ll perhaps demo all this at some stage.

What is OpenSocial?

I just realised there’s no good executive summary for OpenSocial. Every resource fluffs about the “social” aspect and forgets about the UI aspect. The UI aspect, essentially a gadget specification, is just as important as the social aspect, notwithstanding its absence from the “OpenSocial” brand name. I’m not a fan of the name “OpenSocial” for this reason, though I acknowledge it does have more attention-grabbing bling than “open social widget framework 1.0”. In any event, it’s regrettable that most commentators gobble it up hook, line, and sinker; as evidenced by their almost exclusive focus on the social angle.

With no further ado, here’s my attempt at a one-paragraph summary of OpenSocial …

OpenSocial Executive Summary

OpenSocial is a standard for “mini” web apps, called “gadgets”, which are designed to be embedded other websites. The standard informs developers who wish to write portable gadgets, i.e. those which work in any OpenSocial environment; and likewise, it informs developers who are creating such environments. It defines an XML format for applications, typically containing the user interface (HTML/CSS/Javascript) as well as metadata, e.g. author, gadget size, and preferences. In addition, OpenSocial defines a number of APIs, so that gadgets can invoke services such as changing the gadget height and fetching remote content. One particularly important class of APIs are those of a social nature. These enable a gadget to access data and run services related to the user who is viewing the gadget, or the user whose web page the gadget is embedded in. For example, the gadget can – subject to security settings – find a person’s name and location, traverse their social network, and invite them to install an application. Access to social data is not limited to gadgets, however, as OpenSocial also provides a RESTful variant of the social API, suitable for any kind of net-enabled client. OpenSocial was launched by Google in November, 2007, and is to be managed by the non-profit OpenSocial Foundation.

Relative Paths and On-Demand Calls in Gadgets

A problem with the current opensocial gadget spec is that there’s no relative path support. This means you end up hard-coding any references to Javascripts, CSS stylesheets, images, and services which are distributed along with your gadget.

This is not good. For example, you may have a “prod” setup and a “dev” setup. While developing, you will have to hard-code <script> tags and so on to hit the “dev” location, but then for production, you will want them pointing at your scripts in the production location. Likewise, you might want to ship the bundle to someone else for them to host on their own network.

You can deal with it using a pre-compiler tool – you know, using sed-like token substitution to piff in the right location. But a pre-compilation step is a messy compromise – I just want to distribute the code and be done with it. Another solution would be to output the gadget spec from a script, which would let you solve the problem in one of two ways: (a) inline common Javascripts and stylesheets so that you don’t even need to link to them; (b) piff in the right location on the fly. Again, this is not ideal. It introduces a new server-side language and demands the spec server supports it. My aim here is simple distribution of gadgets – as long as you can host a tree of static files, you can serve my gadgets.

The optimal solution right now is far from ideal, but is the best way I know to do it. You use On-Demand Javascript (and on-demand CSS and on-demand <insert resource type here>). First, you work out the gadget spec location, then you manipulate the URL to find the required Javascript, and then you pull it down using DOM manipulation.

I’m using a compressed version of something like this:


  1. var gadgetURL = _args()["url"];
  2.     function loadScript(scriptURL, onLoaded) {
  3.       var baseURL=gadgetURL.replace(/[a-zA-Z0-9_]+.xml(?.*)?/,"")
  4.       if (scriptURL.indexOf("http")!=0) scriptURL = baseURL + scriptURL;
  5.       if (debugMode) scriptURL+="?" + (new Date()).getTime();
  6.       var script = document.createElement("script");
  7.       script.src = scriptURL;
  8.       if (onLoaded) script.onload = onLoaded;
  9.       document.body.appendChild(script);
  10.     }

It’s partly based on a mailing list comment from Arne Roomann-Kurrik. Massaging further, I end up with the following boilerplate block which must be cut-and-paste into each gadget to bootstrap reuse:


  1. _IG_RegisterOnloadHandler(function() { var script = document.createElement("script"); script.src = _args()["url"].replace(/[a-zA-Z0-9_]+.xml(?.*)?/,"") + "../core.js"; script.onload = initialise; document.body.appendChild(script); });

After dropping this at the bottom of my gadget, I know that (a) ../core.js will be pulled down and executed – it is relative path from wherever the gadget came; (b) initialise() will be called once core.js has been loaded. Each of my gadget’s has an initialise() function which does gadget-specific initialisation. core.js is a common library and also happens to include loadScript() in case I want to pull down further Javascripts, and also loadStylesheet() so I can grab a stylesheet with relative path.

All this is not at all ideal, for several reasons:

  1. For all the benefit of neatly using a separate Javascript file, you have to cut-and-paste boilerplate code into every page! But at least the boilerplate won’t have to be changed often.
  2. Performance will suffer as the script is loaded later than it should be.
  3. It relies on the “url” being passed into the gadget; to my knowledge, this is not something you can definitely assume will happen, i.e. it’s not mandated by the opensocial standard that the gadget receives a parameter called “url” identifying where the gadget came from.

I have requested on the opensocial spec mailing list to provide direct relative path support and the response has been positive, hopefully we’ll see it soon, thus rendering large parts of this post obsolete. The solution looks to be rather neat – injecting a <base> tag to establish a base URL which all relative paths work against.

World timezone data

Writing a multi-timezone clock gadget, I found myself needing to convert timezones in Javascript. This is one uncharted area in Ajax/Javascript – unfortunately, there is no timezone library to my knowledge. Unfortunately, there’s no public JSON service to tell you what time it is right now in Tokyo either. I could create one without too much difficulty, but I’m aiming to build a self-contained gadget, which means I want it all in Javascript.

Back to first principles, ZoneInfo is incredibly thorough, but that makes it difficult to use for a single gadget. There is a wikipedia list too, but not easily parsed. (If web 3.0 is all about the semantic web, then wikipedia will hopefully become a better home for structured data too.) I then found “City Time Zones” which is a user-generated, wiki-style, approach. The problem is it doesn’t handle daylight savings, but it will do for now – the user will simply get a checkbox to say if it’s daylight savings or not. Yeah it’s a really ordinary solution, but the only one I can manage if I’m to build the gadget in a day or so.

I extracted from the ZoneInfo a simple list you might find useful. The first iteration is sorted by timezone and I’ve junked geo and other info, so you just have the timezone names, the offset, and major locations.

Tonga Standard Time,+13:00 Nuku’alofa
Kamchatka Standard Time,+12:00 Kamchatka
Fiji Standard Time,+12:00 Fiji, Marshall Is.
New Zealand Standard Time,+12:00 Auckland, Wellington
Norfolk Island Standard Time,+11:30 Norfolk Island
Central Pacific Standard Time,+11:00 Solomon Is., New Caledonia
Magadan Standard Time,+11:00 Magadan
Vladivostok Standard Time,+10:00 Vladivostok
Tasmania Standard Time,+10:00 Hobart
West Pacific Standard Time,+10:00 Guam, Port Moresby
AUS Eastern Standard Time,+10:00 Canberra, Melbourne, Sydney
E. Australia Standard Time,+10:00 Brisbane
AUS Central Standard Time,+09:30 Darwin
Cen. Australia Standard Time,+09:30 Adelaide
Yakutsk Standard Time,+09:00 Yakutsk
Korea Standard Time,+09:00 Seoul
Tokyo Standard Time,+09:00 Osaka, Sapporo, Tokyo
Ulaanbaatar Standard Time,+08:00 Ulaanbaatar
Taipei Standard Time,+08:00 Taipei
W. Australia Standard Time,+08:00 Perth
Singapore Standard Time,+08:00 Kuala Lumpur, Singapore
North Asia East Standard Time,+08:00 Irkutsk
China Standard Time,+08:00 Beijing, Chongqing, Hong Kong, Urumqi
North Asia Standard Time,+07:00 Krasnoyarsk
SE Asia Standard Time,+07:00 Bangkok, Hanoi, Jakarta
Myanmar Standard Time,+06:30 Rangoon
Sri Lanka Standard Time,+06:00 Sri Jayawardenepura
Central Asia Standard Time,+06:00 Astana, Dhaka
N. Central Asia Standard Time,+06:00 Almaty, Novosibirsk
Nepal Standard Time,+05:45 Kathmandu
India Standard Time,+05:30 Chennai, Kolkata, Mumbai, New Delhi
West Asia Standard Time,+05:00 Islamabad, Karachi, Tashkent
Ekaterinburg Standard Time,+05:00 Ekaterinburg
Afghanistan Standard Time,+04:30 Kabul
Caucasus Standard Time,+04:00 Yerevan
Tbilisi Standard Time,+04:00 Tbilisi
Baku Standard Time,+04:00 Baku
Arabian Standard Time,+04:00 Abu Dhabi, Muscat
Iran Standard Time,+03:30 Tehran
E. Africa Standard Time,+03:00 Nairobi
Russian Standard Time,+03:00 Moscow, St. Petersburg, Volgograd
Arab Standard Time,+03:00 Kuwait, Riyadh
Arabic Standard Time,+03:00 Baghdad
Turkey Standard Time,+02:00 Turkey
Israel Standard Time,+02:00 Tel Aviv, Jerusalem
Syria Standard Time,+02:00 Syria
Jordan Standard Time,+02:00 Jordan
FLE Standard Time,+02:00 Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius
South Africa Standard Time,+02:00 Harare, Pretoria
Egypt Standard Time,+02:00 Cairo
E. Europe Standard Time,+02:00 Bucharest
Lebanon Standard Time,+02:00 Beirut
GTB Standard Time,+02:00 Athens, Beirut, Istanbul, Minsk
W. Central Africa Standard Time,+01:00 West Central Africa
Central European Standard Time,+01:00 Sarajevo, Skopje, Warsaw, Zagreb
Namibia Standard Time,+01:00 Namibia
Romance Standard Time,+01:00 Brussels, Copenhagen, Madrid, Paris
Central Europe Standard Time,+01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague
W. Europe Standard Time,+01:00 Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
GMT Standard Time,+0:00 Dublin, Edinburgh, Lisbon, London
Greenwich Standard Time,+0:00 Casablanca, Monrovia
Azores Standard Time,-01:00 Azores
Cape Verde Standard Time,-01:00 Cape Verde Is.
Mid-Atlantic Standard Time,-02:00 Mid-Atlantic
Argentina Standard Time,-03:00 Argentina
E. South America Standard Time,-03:00 Brasilia
SA Eastern Standard Time,-03:00 Georgetown, South America Eastern Time
Greenland Standard Time,-03:00 Greenland
St Pierre and Miquelon Standard Time,-03:00 St Pierre and Miquelon
Uruguay Standard Time,-03:00 Uruguay
Newfoundland Standard Time,-03:30 Newfoundland
Atlantic Standard Time,-04:00 Atlantic Time (Canada)
Falkland Islands Standard Time,-04:00 Falkland Islands
SA Western Standard Time,-04:00 La Paz
Paraguay Standard Time,-04:00 Paraguay
Pacific SA Standard Time,-04:00 Santiago
Venezuela Standard Time,-04:30 Venezuela
SA Pacific Standard Time,-05:00 Bogota, Lima, Quito
Cuba Standard Time,-05:00 Cuba Standard Time
Eastern Standard Time,-05:00 Eastern Time (US & Canada)
US Eastern Standard Time,-05:00 Indiana (East)
Central America Standard Time,-06:00 Central America
Central Standard Time,-06:00 Central Time (US & Canada)
Mexico Standard Time,-06:00 Guadalajara, Mexico City, Monterrey
Guatemala Standard Time,-06:00 Guatemala
Honduras Standard Time,-06:00 Honduras
Canada Central Standard Time,-06:00 Saskatchewan
US Mountain Standard Time,-07:00 Arizona
Mexico Standard Time 2,-07:00 Chihuahua, La Paz, Mazatlan
Mountain Standard Time,-07:00 Mountain Time (US & Canada)
Pacific Standard Time,-08:00 Pacific Time (US & Canada); Tijuana
Alaskan Standard Time,-09:00 Alaska
Hawaii-Aleutian Standard Time,-10:00 Adak
Hawaiian Standard Time,-10:00 Hawaii
Samoa Standard Time,-11:00 Midway Island, Samoa
Dateline Standard Time,-12:00 International Date Line West

Yes, Tonga is 13 hours of UTC and 25 hours ahead of those little-known places that are UTC-12. In fact, Kiribati Istland (not shown here) is +14 so a day and 2 hours ahead of the others. This wasn’t meant to be easy.

Anyway, I simplified the list further to:

+13:00 Tonga
+12:00 Auckland, Wellington, Fiji, Marshall Is., Kamchatka
+11:30 Norfolk Island
+11:00 Solomon Is., New Caledonia, Magadan
+10:00 Canberra, Melbourne, Sydney, Brisbane, Hobart, Guam, Port Moresby
+09:30 Darwin, Adelaide
+09:00 Seoul, Yakutsk, Osaka, Sapporo, Tokyo
+08:00 Taipei, Ulaanbaatar, Perth, Kuala Lumpur, Singapore, Irkutsk, Beijing, Chongqing, Hong Kong, Urumqi
+07:00 Bangkok, Hanoi, Jakarta, Krasnoyarsk
+06:30 Rangoon
+06:00 Sri Jayawardenepura, Astana, Dhaka, Almaty, Novosibirsk
+05:45 Kathmandu
+05:30 Chennai, Kolkata, Mumbai, New Delhi
+05:00 Islamabad, Karachi, Tashkent, Ekaterinburg
+04:30 Kabul
+04:00 Tbilisi, Yerevan, Baku, Abu Dhabi, Muscat
+03:30 Tehran
+03:00 Moscow, St. Petersburg, Volgograd, Nairobi, Kuwait, Riyadh, Baghdad
+02:00 Turkey, Tel Aviv, Jerusalem, Syria, Jordan, Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius, Harare, Cairo, Bucharest, Beirut, Athens, Beirut, Istanbul, Minsk

+01:00 Sarajevo, Skopje, Warsaw, Zagreb, Brussels, Copenhagen, Madrid, Paris, Belgrade, Bratislava, Budapest, Ljubljana, Prague, Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna, West Central Africa, Namibia
+0:00 Dublin, Edinburgh, Lisbon, London, Casablanca, Monrovia
-01:00 Azores, Cape Verde Is.
-02:00 Mid-Atlantic
-03:00 Argentina, Brasilia, Georgetown, South America Eastern Time, Greenland, Uruguay
-03:30 Newfoundland
-04:00 Atlantic Time (Canada), Falkland Islands, La Paz, Paraguay, Santiago
-04:30 Venezuela
-05:00 Eastern Time (US & Canada), Bogota, Lima, Quito, Havana
-06:00 Central Time (US & Canada), Central America, Guadalajara, Mexico City, Monterrey, Guatemala, Honduras, Saskatchewan
-07:00 Mountain Time (US & Canada), Arizona, Chihuahua, La Paz, Mazatlan
-08:00 Pacific Time (US & Canada), Tijuana
-09:00 Alaska
-10:00 Hawaii, Adak
-11:00 Midway Island, Samoa
-12:00 International Date Line West

Also available in cut-and-paste form

FireEagle Developer Event


I discovered at last minute a developer event on Yahoo! FireEagle at Covent Garden tonight and decided to rush down there. FireEagle is pretty intriguing as the first serious attempt at an OAuth API (though Google Contacts now qualifies too). For me, that was the main draw; but the actual service it offers is also compelling.

What’s FireEagle?

Location based services have been hyped for years. By now, you should be walking around and receiving reviews of local restaurants on your phone, browsing nearby tourist attractions, and seeing which of your friends is in your vicinity. However, it hasn’t caught on. The main reason is stovepipes and walled gardens. Your mobile provider might have an API available, but probably restricted access to a very limited set of developers. A mix of privacy and commercial concerns have rendered this whole area practically useless.

Enter the eagle. FireEagle completely opens up this area, by offering a model that is flexible and open, but without compromising user privacy. It’s an API that essentially tracks one thing: Where in the world are all FireEagle users?

In other words, the FireEagle API allows any client to update a user’s location and any client to retrieve a user’s location. Of course, the user must consent to all this activity, and that’s where OAuth comes in – as a way for users to say, for example, “I trust app abc to update my location and app xyz to read my location”. So FireEagle detaches location providers from location consumers, opening up an entire ecosystem.

What kind of clients act as location updaters? You might think it’s all automated stuff, like mobile devices and IP numbers, but actually many updaters are manual. Here’s a sample:

  • Mobile phone app. Anyone with the right access details could write a mobile phone app to use cell tower information, built-in GPS, or any other cues, to update location as the user moves around. This is the no-brainer example of an automatic mobile updater.
  • Twitter. When you tweet with “L: london”, a twitter monitor app could notice that and notify FireEagle. (As with all cases below, you must have authorised the monitor app to do that.) This example illustrates that users aren’t always passive lemmings walking around with a mobile updater app in their pocket. It may be that location data is only ever updated when a user proactively tweets their location.
  • A client that watches you adding geotagged photos to Flickr, and assumes you are in the last location you uploaded.
  • Specialised tracker device. Devices based on GPS (e.g. SPOT) could easily be made to update FireEagle with their location.
  • Car app. Based on GPS, a car’s location could be tracked using FireEagle. (The car, not the driver.)
  • Travel card. (My example.) Theoretically, your travel card could update FireEagle location as you move around. Same for transponder devices in cars.
  • Many, many, more examples.

What kind of clients act as location consumers?

  • Find nearby friends, tourist attractions, pubs, etc.
  • Find currency rate (since you know what country they’re in)
  • Phrases in the local lingo or an online dictionary
  • Location based games
  • Many, many, more examples

Some clients may act as both updater and consumer.


The other thing FireEagle gets right is great concern for privacy – users can give out as much or as little data as they like, and they can stop the service at any time. The first way this happens is with OAuth, which lets you manage which services can perform what actions. You can start and stop this at any time. In the future, there will be a simple client to let you log in from your mobile and control all this. In particular, you will probably be able to suspend all tracking at any time.

Additionally, you can apparently set granularity, so you could expose just a general area, e.g. whiiich city or country you’re in, instead of a particular co-ordinate.

In the future, you will probably be able to authorise a client just for a certain time, e.g. during a conference, after which it can no longer access your data.

At some point, historical data may become available. The team said if this happens, they will allow users to delete and edit their past data.

In summary, the team has been very careful to ensure users have complete control over their own data,

Very Raw Notes from Presentation

Tom Coates is talking about FireEagle.

FireEagle is the old CS classic: a layer of intermediation – between location identification systems and location consumer systems. As a user, I can tell FireEagle where I am and any permissioned app can make use of that data.

London is about the most frequent location for fireeagle

What would your existing/past apps look like if they had location services available?

e.g. Navizon

e.g. ZoneTag

e.g. Firebot – Make it your twitter friend and direct message your location to it.

e.g. BrightKite – cf dodgeball

e.g. Rummble

e.g. Plazes – determines your location via wifi. Then shows where you are on map, people around you, etc etc. And updates FireEagle

WikiNear – ~1M geo-tagged articles in wikipedia. Wikinear exploits that data – as you’re walking around, shows you the closest POIs that are in wikipedia.



Fireball – where your friends are

Fire Widgets – weather where you are, nearby Flickr photos

Moveable Type

Facebook “friends on fire” app – shows where your friends are and updates your Facebook status

Could be great…

Spot – specialised comms/phone device for backpackers, aid workers, etc. ~100pound for device, 100pound a year and keeps updating your location every� ten minutes. Doesn’t integrate yet but great example if it did

Ambient Orb – e.g. changes colour as you move away


Geotagging all user generated content – cinema listings, local traffic, local TV stations, nearby friends, weather forecast, local exchange rates, public holidays, windspeed. A lot of this is on wikipedia thanks to geotagging.

Friends and family widgets. e.g. where they are in the world, what time it is, weather, etc. (A gadget for each person.)

Last.FM – On cracked iphone, can get mobile scrobbler on iphone. What if it recorded where you were, then you could see which songs people play in particular areas. Cool!

Pacmanhattan – Lots and lots of game ideas (idea: scavenger hunt! reminds me of geocaching)

(later mention: geocoding animals, e.g. track migration)

Later on, expecting it to track historical data. (and since it will be user-modifiable which means you could back-track your entire life! (or someone elses eg fake shaekspeare))

Building an APP


1 – Get API key 2 – User authorises your app 3 – Make API calls to Fire Eagle Outside.In -�

Who’s within an area

Each consumer key and secret identifies an application using Fire Eagle.

User Authorises ….

There are three models and the difference is purely to do with differences in (app triggering web page) and (web page triggering app). Web: Can trigger in both directions Mobile: Can’t trigger in either direction (maybe, but can’t assume it) Desktop: App can trigger web page, web page can’t trigger app

Web App model: Request token

I asked which model was used for widgets. Answer: Desktop. (Makes sense, with current technology. Web model would cause redirection from container. Later on, Opensocial will have oauth built in.)

Core Concepts

Note: social graph (user and friends) is beyond scope

location – point or bounding box location hierarchy – set of locations

Exposed RESTfully:

  • user() – duh
  • lookup() – provide location string and choose from list of resolutions (which “london”??)
  • update() – duh. call it and it “moves you”
  • within() – ?
  • recent() – “map of soho and everyone in there” OR “last 100 updates from my users”

walking through

Will probably support xmpp/Jabber too – more appropriate than HTTP for this

Hoorah for Aptana Cloud

Aptana Cloud has now been announced. This is exciting news and a step closer to server-side Javascript world domination. You don’t have to use Javascript, as the platform offers several engines, but from my perspective, the most exciting thing is the inclusion of Jaxer. So it should be easy to deploy server-side Javascript to a completely scaleable platform.

As for the more headline feature, it is a general cloud play. It will target the existing Amazon/Google/Joyent/others clouds (a “designed to go meta” as Dion puts it) rather than being a YAC (yet another cloud). My personal experience with the much-hyped Amazon EC2 has been nothing but pain, pain, pain. It might be fine for your run-of-the-mill Web 2.0 startup, but casual use? Forget it. Give me bog-standard ssh any day. If Aptana can solve that problem, and I have no idea if they can, but if they can, I’m sold. Key to the strategy will be integration with the Aptana IDE. That said, I find the Heroku idea of Cloudies (cloud IDEs) fascinating, so it would be nice if a product like this also offered some rudimentary cloud editing support in the future. (Enough to at least fix a critical bug from the comfort of an internet cafe.)

Kevin Hakman got in contact with me after the Javascript Grid article and kindly offered to let me review the beta, which is still on the cards, so I’ll let you know how it goes once I get access. I’ll also be interested to see how much more expensive it is to hit a Jaxer script versus a PHP script.

Today, Aptana unveiled its vision for Aptana Cloud, the next (but not last) aspect in Aptana’s strategy for providing an “End to End Ajax” suite of open-source based solutions for Web developers that use scripting languages. See Open for Deployment
  • The “engines” in Aptana Cloud are comprised of some of the most widely used and popular open source infrastructure: PHP, Apache, MySQL
  • Aptana Jaxer, the open source Ajax server based on the Mozilla browser engine, is also provided.
  • Ruby on Rails support is next in line. Complimentary to existing cloud suppliers
  • Architected to compliment leading Cloud providers like Amazon, Google, Joyent and others. Integrated right into your application life-cycle
  • The Aptana Cloud IDE plug-in will connect your Cloud instances right into your Aptana Studio/Eclipse application development, deployment and management life-cycles featuring:
    • On demand instant deployment to the Cloud
    • One click sync between your projects and the Cloud
    • Subversion source control
    • Remote DB Explorer and admin
    • Operational monitoring and notifications
    • System dashboards, logs and stats
    • Google Analytics integration
    • … and lots more as described at
    Early Access Program
  • Those interested in the early access program can request such at
  • Testing OpenSocial Apps – Current Challenges

    At present, the OpenSocial containers are new and the whole process is still quite difficult from a developer’s perspective. These are unfortunate barriers to adoption which the containers could overcome with some redesign.

    The challenges at present are:

    • Manual signup and approval process required. Even to get onto the sandbox area, you have to go through a manual signup and approval process, which usually takes a day or two. A human is in the loop verifying your details. At that time, the developer may have lost interest, or the mail may never get to them.
    • Lack of test accounts. The sandbox accounts usually can’t interact with non-sandbox accounts – that’s what makes them “sandboxes” and this is a wise policy. However, what do you do, as a developer, when you want to test with a large group of friends? You could friend other developers, but testing is going to get a little tired if you have to keep asking them what happened. The problem is the manual signup process – you have to add new users with fake details for approval by the container – weird! On Orkut at least, you can also invite friends from your test account, so it’s possible. And, oh yeah, I hope you get a kick out of CAPTCHA. You’ll be filling in a *lot* of CAPTCHA forms as you build up your social network of imaginary friends! One to create the account, one to verify email, one for good luck here, one more just because why not. And that’s for each user on each container! If I was running these containers, I would make it even simpler and just create an initial block of 10 fake friends (some friends with each other…pick your favourite soap opera) and let the user seamlessly add new ones too.
    • Older versions and Missing Features. Ning and Plaxo are hosting OpenSocial 0.5, whereas 0.7 has been out for a while and 0.8 is about to come out. I can’t blame them for not upgrading all the time, but it still makes development more difficult. As for missing features, I noticed this with Hi5. It’s a good implementation, but still missing a critical feature – UserPrefs. This is just the multi-container nature of OpenSocial.
    • Slow code-test cycle. When testing with a container, you have to change the gadget on the server and the container will then reload it and render it. This reloading process will always take some time, but the container can do as much as possible to eliminate any other delays. Unfortunately, they don’t make it easy at present. I refer specifically to caching. You obviously don’t want your gadget to be cached during code-test cycles. Caching is usually enabled by default, even in the sandbox. That’s kind of dubious – you would think a sandbox should load the gadget each time. But okay, I can accept that decision as it’s useful when you’re testing the gadget 100 times not to be re-downloading it all the time. However, it’s usually not clear or documented how to suppress caching when you want to. Again, the containers should be making it dead simple if they want to encourage development…how about a caching on/off checkbox somewhere in the gadget chrome or settings menu?

    There is a lot the containers can learn from Facebook, and they will need to for OpenSocial to really take off and compete against it. For comparison, here is how Facebook deals with the issues above:

    • Manual signup and approval process required. Facebook makes this completely automated. You create a normal Facebook account and simply visit a special URL to make it a developer account.
    • Lack of test accounts. It’s easy to create test accounts in Facebook – you just keep creating normal accounts and flipping them to become developer accounts by visiting that special URL.
    • Older versions and Missing features. With Facebook, there is only one implementation, so only one definitive version of the API. There’s nothing OpenSocial can do about this directly. It’s simply a consequence of the “Write Once, Run Many” aspiration and the only way for the community to deal with it is to be better in other ways, and to at least be very explicit about what each container does and does not support.
    • Slow code-test cycle. This doesn’t arise in the same way because the model is either based on an iframe directly to your site, or FBML you enter into a form. The OpenSocial gadget model – an XML sitting on a server somewhere – is neater as there’s no form involved; everything’s encapsulated in the XML file. However, it does introduce the whole question of caching and the containers should be doing all they can to simplify the development process to that end.

    I’m a great believer in the OpenSocial vision; hence, I hope the containers will be working to minimise these obstacles. Right now, it’s okay for professionals, but there are enough hurdles there to hold back an army of potential hobbyist developers from uneashing their creativity on this platform.