Flapjax in Denmark

Shriram will be speaking about Flapjax at three venues in Denmark:

• The JAOO Conference, 2007-09-24
• University of Aarhus, Pi-Lambda Seminar, 2007-09-25
• DIKU/ITU/Roskilde, Copenhagen Programming Language Seminar, 2007-09-27

Flapjax in India

Shriram will be giving two presentations on Flapjax in India, both in the context of larger education- and research-related events. The first will be on Monday, December 17, at the Technopark in Trivandrum, hosted by IIITM-K. The second will be on Saturday, December 22, somewhere in Bangalore.

Lifting Tutorial

While not a material development for Flapjax, this tutorial on lifting explores some of the internals of Flapjax: how events and behaviors are implemented, and how plain old JavaScript can operate on Flapjax data structures. It should be accessible to readers familiar with the language, no crazy academic credentials required.

Commercial Feedback (Suppressed)

The folks at untyped have written a research conference paper about their experiences building a commercial Web application. Unfortunately the page limit forced them to excise their feedback about Flapjax. Their blog post has a bit of both positive and negative feedback about Flapjax. We hope to work with them to fix the problems so they'll have a more positive report in the future!

Data Flowing Down Telegraph Avenue

Flapjax is the inspiration for a very elegant project in the compilers course at Berkeley.

Tierless Tieranny

There's a new buzzword sweeping through Web programming circles: tierless languages. These are languages that help nullify the traditional three-tier architecture from the perspective of a programmer. So far, so good (to some extent, anyway). What baffled me was that I was recently at a meeting about Web programming and Web services, at which Web programming languages were classified into two kinds—tiered and tierless—and Flapjax was put into the former category.

Allow me to strenuously object.

It helps to draw some simple pictures. First, there's the tiered world:

In a tierless world, you write a single program, in which you can annotate some parts of the code as running on the client. As for the database part, you effectively program in a stylized supersubset [sic] of the language, which an optimizer knows to translate to efficient SQL. The picture for the tierless world is either the same, or just one big blob (technically, it's a blob that unfolds into the tiered picture).

Of course, this is all wonderful if you have control over the server and the client, or if your client wants to talk to one server only. As soon as it tries to gather data from multiple servers—as in a mashup—you lose this level of control, because you can't approach Google and ask, “Would you please rewrite your module in my new programming language?” (Well, you can ask, but you can also guess their answer.) At that point, the notion of tierlessness ceases to make sense, because you can't meaningfully control the world.

So where does Flapjax sit? We do provide one for data storage, but that should really be thought of as a special case: a lightweight specialization of the general Web service API. In general, we emphasize speaking to multiple servers and provide language and library support for doing so.

There is an intermediate world, represented by Hop:

In the Hop model, the broker lets you get around current JavaScript restrictions by making the broker the single agent who can talk to multiple sites.

We thought for a while about whether we should adopt the Hop broker model, but ultimately rejected it. Here's why. Where should the broker run? Running it on the client is attractive in that the client can then, for instance, serve up local files; but I'm not going to be able to run the client when I'm in an Internet cafe. So perhaps it should run on the server; but in that case, it's just another server, and the fact that it speaks to other servers is of no real relevance (since servers have always had the freedom to do that, and exercise that freedom transparently). Furthermore, the security issues that surround circumventing the same-domain restriction are complex, and the broker is not a sufficient solution. Finally, it is nice to be able to communicate with the local host (for files, for instance). But if you have a language already well-tuned to communicating with services, the broker becomes just another service, and does not need a distinguished status. So that's the Flapjax model:

We don't have a name for this model. We should, because names lead to the uptake of ideas. But the problem is, as Michael Greenberg pointed out, this model already has a pretty good name. It's called the Internet.

Presentations

Shriram will present Flapjax on Friday, February 16 at Tübingen and at Darmstadt on Friday, February 23.

Presentation

Shriram will present Flapjax at the LFCS Lab Lunch on Tuesday, November 14, 2006.