2006/10/30

Meet Us!

Want to talk to a developer of Flapjax? Want us to stop by and explain what it's all about? Meet us on the road! Shriram will be in several places in the coming months, and would be happy to stop by and give you the lowdown. Precise dates are on his calendar. Roughly: in Nov 06 he's in Edinburgh, UK, and can make it to most places in the UK. In early Dec 06, he's in Oxford, UK, Lausanne, Switzerland, and Paris, France. Most of the rest of Dec 06 he's in Bangalore, India. In Jan 07 he'll be in Australia, including a week in Sydney. He will be traveling a lot during the spring of 07, including Germany, Portugal, and a few universities in the US.

2006/10/23

Application Manager Update

I have added compiler support and a measure of documentation to the Application Manager. I invite users to try it out.

You need to log in in order to create, upload, and publish applications.

2006/10/22

Discussion List

Your wish is our command. We now have a discussion list.

We may not have the config options quite the way you'd want them, so show a little love. Do tell us if you see problems.

It may be a bit confusing to have both a blog and a discussion list. I think the blog is a better medium for posting updates and status information, while the discussion list is better for code minutiae. We'll figure this out as we go along. Advice always welcome.

2006/10/21

Streaming Data

In an earlier comment, Julian Morrison suggested creating a server-side protocol. I agreed but said we need to do more work before we can publish something reasonable. I also pointed to an interesting bit of ongoing work, namely Opera's event streaming API, which Kim Burchett brought to our attention. I felt it was worth hoisting this from the comment section because I wanted to point out that APIs like this play directly to Flapjax's strength. Of course you can program against an API like this using callbacks (which would be implementing upcalls), but it'd be so much nicer to just bind to the data stream and let the language do the work—which, of course, is just what Flapjax would let you do.

For now we haven't built a binder to the Opera interface for three reasons: (1) we're not aware of much server-side support for it yet, (2) it doesn't appear to be a client-side standard either, and (3) there are some questions about its definition (as usual, Kim gets past the superficial and asks the relevant questions: see her message on the Opera site linked above). But the Internet is definitely moving in the direction of higher-level data abstractions, and we think Flapjax is well-suited to them.

Networked Persistence

In a comment, Neel Krishnaswami asked us to discuss networked persistence. Here are some preliminary thoughts on this.

The most important thing about persistence in any context is that it should fit naturally with the language. This means lots of things: internal-external data interchange; persistent storage identification and management; hooking up to the language's control model; and more. For now I'll discuss these three points. Notice that the questions themselves aren't really about networked persistence, but the network will show up in each of the answers.

Data interchange on the Internet naturally demands an “XML story”, and lots of language research is trying to wrestle with this. If you step outside research and spend some time in blog-space or studying Web service APIs, you see a very interesting trend: the growing acceptance and even promotion of JSON. Because JSON obviously integrates nicely into JavaScript, and its support is increasing, we're ducking the XML question entirely for now. In fact, our Web services API automatically converts XML data into JSON for your convenience.

What is persistent storage? On a local system, computer scientists find it useful to categorize at least three different kinds of storage: the database, the persistent heap, and the filesystem. (And that's arguably just a 1970s view of systems.) We can distinguish between these along several dimensions: the object model, the power of query, the style of naming, the interaction with processes, etc. In Flapjax, though, many of these dimensions lose their relevance for two important reasons. First, we don't have (and don't want) a true distributed operating system, so the “process” boundary dies at the network interface (with end-to-end services taking its place). Second, network latency greatly distorts the cost models. So some unification of these concepts may be possible. For now, Flapjax gives each user a “home object”; their data are held by fields. From the program's viewpoint it's just a persistent object, but the user can think of fields as a pun for subdirectories, and use the object-browser like a file-browser. What we definitely don't have is a story on search, aggregation, and other functions you get from SQL. We have various thoughts on this, ranging from leveraging XPath to letting users define schemas, but (indeed, therefore!) this is very much an open question.

The control front is somewhat obvious: because Flapjax computations are time-varying, changes must naturally be pushed to the server, and server changes must naturally trigger renewed computation on the client. Defining this crisply has proven to be somewhat tricky. One issue is handling aggregate data, which Michael Greenberg is studying from first principles. The other is how to deal with multiple clients that write simulaneously. Obviously there is already research on this topic, but we do have our hands tied by the lack of server-push, the sheer number of clients that may be accessing a datum, existing APIs, etc. We have our own distributed algorithm that helps with this, but just defining “reasonable” behavior is tricky: if you don't get it right, a client who is sharing a writeable buffer will see the new characters they type disappear before their very eyes.

We need to clean things up a little more before we say much. My reticence isn't in the usual academic “I have a paper coming up and I don't want someone to scoop it or find the flaw in it before it gets in” manner—rather, we really do have more design work to.

And, of course, we welcome feedback and prioritization.

2006/10/19

Compiler!

The downloadable compiler is here! (Well, sort of.) To be precise, the compiler is now available as a web service. You can now download a script which will automatically send your page to our server and return the compiled version. So you can just type: $ fxc -o mypage.html mypage.fx.html and it will do the right thing. Download the script here. (You might need to right-click and say "Save Link As...".) It will work on any computer with Python. A Windows version, which will not require Python, will be available soon.

2006/10/16

IE Progress

As you can see, we've not only been making Flapjax work on IE, we've also been testing the demos and gradually adding the IE icon where we're pretty confident. Of course this is JavaScript-and-browser land, a minefield of incompatibility...but IE support is definitely looking up.

2006/10/13

Downloadable Compiler

Some of you have asked for a downloadable compiler. We didn't expect the demand for it so soon, but we're working on a solution to this problem. Please expect something within the next few days. We'll announce it here on the blog.

IE Problems

We're aware that there are problems using Flapjax in IE. We're working on them right now and will have fixes out soon. Indeed, even as you look some of the demos should be working.

2006/10/06

Welcome to Flapjax!

This is the notification site for developments about Flapjax, our new language for developing Web applications. Flapjax has six important characteristics:

  1. It is event-driven and reactive.
  2. It reduces unnecessary code with an in-lined template system.
  3. It provides a reactive, persistent store that automatically updates on all clients sharing the same data.
  4. It enables convenient sharing of data with other users.
  5. It implements access-control to channel this sharing.
  6. It provides libraries to connect to external Web services (thereby enabling client-side mash-ups).
Flapjax is built entirely atop (and is syntactically identical to) JavaScript, and can thus run on traditional Web browsers without the the need for plug-ins or other downloads.

Shriram, for the Flapjax Team