Wednesday 20 January 2010 (05:13PM)
Since the end of last year I've been spending quite a lot of my spare time experimenting with FluidDB as a platform for web-development. The result is a still incomplete application that I call Flow (the source-code is hosted on GitHub).
I'll let you pause a minute while you work out the circularity of that last sentence. ;-)
To make things clearer I've cobbled together a short screen-cast that attempts to demonstrate what I've been up to. (It's very rough and ready, but you'll definitely get the idea.)
It's VERY incomplete, hardly tested properly, extemporised (rather than designed) and needs a lot of TLC – just a proof of concept really. Nevertheless, as the video demonstrated, you can:
To use it properly you'll need to register for a username and password here:
Here are some of the development highlights…
Lets just remind ourselves of how FluidDB is organised from the point of view of data / schema:
This is all we need to understand for now. (FluidDB's "killer feature" is actually its permissions system and the implications thereof. It is so important that I'll save that topic for its own blog post later. But one step at a time…)
So how does FluidDB act as a web-server..?
Simple really (and apologies if this is too simple an explanation – I don't like to assume too much technical expertise)...
Remember that FluidDB is RESTful in that its API is exposed through the HTTP protocol (y'know, that thing the World Wide Web is built out of). So, if I want to retrieve the value of a tag/object association I simply HTTP GET a URL – just like a web browser does for web-pages.
So how about I create an object to represent my web-application, add a bunch of namespaces and tags that map to the names of the files and directories needed for the application to work and then associate these tags with my application's object? Of course, I make sure the tag/object values are the contents of the files and that the mime-types are set properly (e.g. values for tags mapping to .html files have the mime-type "text/html").
Hey presto… FluidDB is a universal web-server.
So we have a server for our application, but FluidDB doesn't allow any server-side scripting. This means we need to put our application's logic somewhere else – the only other place being on the client's browser.
If you've still not figured out why this is important, take a look at these two images Aaron has created (extracted from this presentation and used with permission) to show the difference between "regular" web-application development and that promoted by CouchDB and (now) FluidDB:
Sammy allows us to live in a Lisp like "code is data" world with no web-server / web-framework playing piggy-in-the-middle. The database is the server and the framework is Sammy-as-data running on the client.
In order to create or update a tag on an object the API requires a PUT request containing the appropriate value. Unfortunately, if the data we want to send is not text based we have a problem.
The usual way to upload binary data is to use an HTML input element with the "type" set to "file". Unfortunately, forms can only use the POST and GET HTTP verbs (this seems an amazingly bad decision – surely they should only support POST and PUT..?).
Since version 3.0 (or 1.9 of the Gecko engine that Firefox uses) it has been possible to do this with the getAsBinary() function. In fact Mozilla have also provided the rather useful getAsDataURL() and getAsText() functions too. These are definitely non-standard and more information about them can be found on Mozilla's website.
Unfortunately, this means I'm stymied for the other browsers and I'm not sure of the best solution. Of course, extracting textual data from a form is easy on all browsers so this only affects binary data. Nevertheless, it's a problem that probably should be solved if such database-hosted applications become popular.
I'll keep plugging away at Flow and will post updates on Twitter.
I also have to give a presentation in March at ThoughtWorks in London about FluidDB. I was thinking… it might be fun to create a "presentation" application with FluidDB and Sammy. Something along the line of DOM slides, AJAX-S or S5.
Who knows… it might actually be useful…
Oh, hang on… some guy called Aaron Quint has already done it with CouchDB.