Client-Side Storage in Javascript

Wednesday 14th May, 2008

Thomas Frank published an awesome hack back in January. Somehow I missed it at the time, but the ever-vigilant Simon Willison picked it up yesterday.

The short version is that by serialising a data structure to the window.name property in the browser DOM you can store up to 2MB (much more in some browsers, eg. IE:32MB, Safari:64MB) for the life of that window object, so a single-window session (multiple tabs or windows open on a page at the same time would not have access to the same data).

Besides from begging the question of what browser developers have been smoking, this isn’t a revolution… The HTML 5 working draft features structured client-side storage so this was already on its way via a more formal route. There are also other methods in place to accomplish similar things, for example Dojo uses the Flash plugin where available to achieve client-side storage.

That said, I’d be surprised if this method didn’t sneak its way into a few codebases here and there due to it’s simplicity, broad browser support, and immediacy… and once Javascript developers become more accustomed to the concept of client-side storage we may well see a flurry of new techniques built on client-side storage.

Advertisements

Google Reader as a Social Tool

Tuesday 13th May, 2008

Google Reader has recently added the option to comment on your shared articles. I like Google Reader, and I like the option to share articles with my contacts. I actually found myself wishing for this feature a while back.

Having thought about it however, I have two problems with the concept of sharing articles via Reader, one is a problem of functionality and the other a problem of scope.

Functionality

Google Reader is not currently a conversational medium, yet sharing articles is a likely starting point for a conversation. Without the ability to converse users have to shift to another product in order to continue the discussion that was started by the sharing of an article. If that context shift is seen as being more hassle than the comment is worth then the user making it probably wont bother, and you’ve lost that social interaction and hence possible value.

Scope

When I share an article via Google Reader, only my contacts can see it. That could be a sensible design choice (after all some people aren’t interested in broadcasting themselves to the world) if all of my contacts used Google Reader, but they don’t. When I share an article, only the 3 friends that use the product can see it. Nor is it really that appealing to ask people to subscribe to my Googler Reader Shared Items Feed (in addition to my blog, photostream, etc.) since I already have enough feeds and in any case I want to be able to comment and discuss the articles I find.

Suggestion

So what’s needed here is really a medium that can simply share articles, and at the same time allows commentary and conversation. A blog is a much more suitable medium for that conversation, but I already have a blog, I don’t want two. It’d be nice if there was some convergence here without having to use an aggregator like Friendfeed (yet another login).

What I think Google should be working towards in this area is something that allows the ease of sharing an article with the flexibility of blogging. I as a Google user should be able to aggregate all of my content at username.google.com, and allow friends to subscribe to the whole thing or to subcategories. Whats more, I should be able to use open standards to pull data from other services into my aggregated feed, so if I like to use Delicious for bookmarking I could configure that as username.google.com/bookmarks.


Processing ported to Javascript

Friday 9th May, 2008

One of my favourite chronic overachievers John Resig has ported one of my favourite programs, Processing, to one of my favourite environments, Javascript, using the Canvas tag.

From first appearances it seems like performance is good. Well done John.


RDF and Freebase’s Graphd

Tuesday 6th May, 2008

I’ve just spent half an hour reading a fascinating article about Graphd written by Scott Meyer. Graphd is the in-house data storage system used by the social database Freebase. It’s either RDF, or a custom relative of RDF, but Scott doesn’t say.

Since (like the majority of application developers) I’ve had my head buried deep in the data storage sand of SQL and RDBMS for the last decade it comes as quite a shock to me to find a world of techniques that bears no relation to the structures I’m used to, and that some people have been doing this all along.

Rather than ignoring the elephant in the kitchen I think it’s best to pack my mosquito net, don my favourite pith helmet, and venture forth into that kitchen to find out what lurks in the biscuit tin of wisdom.

Resource Description Framework (RDF)

RDF is a system for recording data that works by allowing you to record statements about objects and their relationships. This is very different to a relational database because it becomes pretty trivial for you (or even your users) to expand your database structure. The data defines the database structure. RDF is to RDBMS what a folksonomy is to a rigid ontology.

It uses a data structure called a “triple” to record data.

Triples

A triple is a simple statement, the quantum unit of knowledge. You can’t cut it up any more without losing information. They consist of a subject, a predicate, and an object. Eg:

  • “My office (subject) is in (predicate) London (object)”
  • “Alice (subject) went into (predicate) the looking glass (object)”

The main difference between a simple list of statements and a proper Triple Store is that ambiguous names such as “Alice” are replaced by unique identifiers, either IDs or URIs. Vague non-machine-readable predicates are also replaced by defined relationships.

Huh?

But what does all this mean?

My brain tends to work by example. Concepts are all well and good, but concrete examples are king. RDF is a semantic storage technology, and in that space we have a few players. Interesting examples are people like Freebase (as mentioned above) and MusicBrainz (an open music database). These organisations are not only allowing contributors to enter data, but allowing them to define new types of data. This takes something that (in the land of the RDBMS) belongs to the product manager, architect, and DBA, and puts it into the hands of regular users.

RDF may have been around for a long time, but I don’t think we’ve seen it’s full potential yet.


Automatic Exploit Generation

Thursday 1st May, 2008

This somewhat scary story could up the arms race between software producers and black-hat hackers. The concept is that by comparing two versions of the same program, one with a flaw, and one with that flaw patched, you can automatically generate code that exploits that flaw.

It’s (hopefully) a way off being an immediate and active threat, but it could mean that services such as Windows Update could themselves act as a resource for those looking for exploits.

Possible repercussions might (and I’m guessing here) include techniques that make it more difficult or expensive for hackers to use this technique, such as reducing users right to choose when to install security updates, attempting to introduce false positives to slow hackers down, or increasing the the number of changes bundled with each release.


Ultraviolet Hat

Thursday 1st May, 2008

This is an excellent article by David Weiss about overconfidence and risk aversion.

If Blue Hat Thinking is a mode of thinking about processes and big pictures, perhaps detecting poorly calibrated risk in your own behaviour is an Ultraviolet Thinking Hat.