Lambda the Ultimate

The thing that bothers me is how to model multiple forms/events. One can mimic HTML and treat submit buttons just as input fields, so they just get passed as values to a continuation.

Sometimes, however, I see it more natural to say we have not one continuation waiting for a form to be submitted, but as many continuations as submit buttons (nothing, of course, precludes their closures from overlapping, so there is no overhead or lack of expressability).

This approach is not limited to Web, of course. I think it may be used for any events-based application.

Are there any servers/frameworks that go this way? I was not able to conjure a good enough Google request :-)

Continuations and threads: Expressing machine concurrency directly in advanced languages is a very interesting paper dealing with continuations and events on a very low level.

Hmm, I may write a compiler one day, if I continue reading low-level stuff :-)

On the serious side, this paper describes nicely the difference between a continuation and a thread (it's obvious, but an eye-opener for me).

If you're interested, I can e-mail you the paper.

My paper may not be quite what you're looking for in your original post. With the PLT webserver continuations are done at URL granularity, so multiple submit buttons on the same form will lead to the same continuation. The dispatch to multiple continuations is mechanical, though, and not too much of a problem to do manually.

I totally agree with you conceptually, though. Each submit button should have its own continuation.

The leakage stuff (that Cite Seer reference) is something I discovered after I wrote the paper. It's a more general look at what I address and I think very worth reading and studying further. Basically, when a user clicks a link or presses a button, but your code has to dig through the results and figure out what he did, and then do a dispatch, that's leakage. Going directly from URL to continuation is leakage-free.

Thanks, I finally got the paper. Probably some ISP glitch, or LtU generated too much traffic ;-)

With the PLT webserver continuations are done at URL granularity, so multiple submit buttons on the same form will lead to the same continuation.

In our project we use hidden forms as a transport instead of submitting directly, so each button may submit to a different URL. It works for a long time, the only problem is, of course, lack of browser history, and therefore, of a back button. That hurts usability enormously. I just tried to analize the situation formally, in an effort to find the best of two worlds. From a technical point of view, we can attach some additional client-side scripting to buttons, so they generate different URLs even for normal HTML forms. In this case, though, we will have to forfeit traffic savings we have now - in many applications each client-server roundtrip redraws just a portion of the screen.

Looks almost as if we need to hide browser's native navbar, and introduce our own for manipulating our internal history :-)

And yes, I wholeheartedly recommend the leakage paper to everybody, it's a must to read. It just gives a name to a concept everybody feels is there (ok, at least most of my collegues feel :-) ).

Using an "old" continuation should delete any continuations later in the tree.

I'm thinking of something vaguely similar for a data processing language/system. One processes data using a sequence of functions, forming a "line" of mutated data. The user can then step back up the line and change a parameter, either creating a "fork" with new data, or triggering a re-calculation of later data (or both :o). These trees/sequences can then be exported to other uses, applied to new data, etc.

(In practice, not all data would be stored, and much might be deleted for space economy, since it can be recalculated on demand (data that has expensive processing costs is less liekly to be deleted). This seems somewhat like weak references in a strictly functional language (which someone pointed me at a while ago, but which I haven't yet followed up)).

Off topic: wasn't there a post of Ehud's a while back saying something vaguely to the effect that Monads were not a good solution for IO? I can't find it, and have a comment that might (depending on teh details of what he did actually say) be relevant...

I meant that if we use custom transport (not just submitting HTML from), then a browser does not update its history, and there is just no state to return to.

Otherwise, back button should be ok for a continuation-per-button server.

Just minor cosmetic problem: personally I would be more pleased to see disabled buttons/links instead of getting reply that this continuation was GCed (discontinued?). This, of course, is betting for even more tight integration with client side, and probably should be left for non-HTML clients.

On the other hand, you talk about forms and buttons. If you're using HTML then you can't select continuations by URL *and* have one continuation per button (since a form can contain more than one submit button) unless you dyanmically hack the form URL with Javascript tied to a button action.

I do :-)

The whole framework is trying to provide a rich client on top of a standard browser. It's using JS heavily, hacks DOM heavily, so it has it's dark side.

By custom transport I mean our buttons are not just submit-type-inputs. They don't even call submit() of the form. We encode the URL manually (using app independent JS), and submit it through invisible frame. We actually use HTTP, but push it down the stack, effectively implementing our own protocol on top of it. E.g., our JS is responsible for interpreting the response from the server. Kind of applet or ORB, but implemented in terms of HTTP, HTML, JS and servlets. And you bet we know official MSIE bugs by heart :-)

Oh, I got offtopic :-)

I thought you were choosing between a single continuation or many

No, now I already bought multiple continuations, the papers in the thread being the last evidence I am on the right track. Well, not THE right one, but I like it :-) May end up using Scheme both client and server side (gradually becoming fed up with Java). Or is it possible in English to be fed up by a drink? :-)

document.forms.main.action=action document.forms.main.submit()

It associates closures to URL's in a manner similar to Peter's paper. It also has 'wizard' style page flows built in giving back, cancel, next and finish buttons 'out of the box' to save writing the closure code for that each time.

I use Sisc Scheme for the web server and all the continuations are serialized to storage allowing the server to be shut down and restarted in the middle of transactions and have them continue without interruption. The downside of this approach is the storage for the continuations. Currently I'm looking at 20-30k on average for a 5-6 page flow. These continuations hold all state btw. The main reson for the large size is that the current system has drop down combo boxes with data pulled from the database and this takes room in the continuation. I need to factor this out in a later revision.

I've taken the approach of 'expiring' the continuations after a period of time, and any request for that expired continuation going back to the main system screen after an informational message. Ideally I'd like to keep them around for a long time but disk storage for a busy system is an issue.

A bit. But it all sounds pretty interesting, so keep us informed...

Wow... that seems like a lot of data. Can you push some of it off to the client? One cool insight that has been shown to me is that the environment on the server side is semantically identical to form fields on the client side. Likewise, the store on the server is the same as cookies on the browser.

Though, as you say some of it is from the database, so a refactoring could fix that.

Paul Graunke, et al. have a paper Automatically Restructuring Programs For The Web that avoids storing continuations by pushing stuff onto the client, encrypted so that the it can't be tampered with. I don't know how ultimately practical their solution is but it's an interesting consideration.

_pEt3

<offtopic level="dirty"> The interesting part of our job is, clients themseves design GUI, and just want us to implement it in Web app. This means we do not have a say in GUI design at all. Therefore, screens with hundred input items are not uncommon, tabs nest to 4 or 5 levels, there are always-on-top modeless dialogs and other monstrosities. This is why we implemented rich client infrastructure.

OTOH, there was a strict prohibition of Java or ActiveX, so we did it in JS.

A test for your framework: main window (with tabs) has multiple lists of the same object type (say, products). On the first click on an 'Add' button of any product a new always-on-top modeless dialog must be open with a selected product being the only in the dialog's list. On subsequent clicks on 'Add' in the main window corresponding products must be appended to the list. Now the tricky part: the list in the dialog has editable fields, and upon adding a product to the list, the changes to previously added products must not disappear.

Sounds scary? It is scary. </offtopic>

This seems ok if there is no side-effects in the application, which for me means it's not an application, but just a content-serving system.

Otherwise you either cheat your user, not saving everything in the continuation, or end up saving versions of the whole server-world on the client (think DB transactions with sufficient isolation level).

I do recognize that saving everything is not only very coslty, but in many cases counter-intuitive for the user. Classical example - shopping cart. The problem is, no framework can differentiate automatically, what is to be saved as a part of continuztion, and what not. Speaking in hardware terms, what lives in the registers, and what on the heap. I believe this distinction to be very application-specific - decided by app developer (or even user-specific - decided by user's preferences).

This statement is not to diminish the value of the paper you mentioned, just to open a new discussion point (continuation?).

The one that (unfortunately) doesn't exist...

There was (is?) a Scheme-based "flow-management" (codenamed Schecoon), as well as Rhino enhanced with continuations (proving the saying that JS is just alternative syntax for Scheme ;-) ).

I tried to use Cocoon in practice too soon (three years ago.. maybe four?..), which was a mistake. That unsuccessful attempt killed my interest to the project that seems to be still alive and kicking...

Avi, thanks for the pointer. I am quite busy preparing for a vacation, so just noticed your post.

...

Aha, seems vaguely familiar: The most common kind of object to get registered in Seaside are what in Smalltalk are called ValueHolders, also sometimes called "boxes" - objects that consist solely of an instance variable and a getter/setter for it. One of the "right" things we did in our project (I think) was introduction of boxes. Absence of developer-visible references in Java is one of little things that make the language barely usable for many purposes...

I suggested that components being heavyweight resource, allowing them to cross continuation boundaries should be prohibited. Automatic release doesn't seem a good solution to me, as it would mean that script variables would hold released components, thus leading to unpredictable behaviour (think about stateful pooled components). So my opinion is to raise an error if there are some unreleased components when a continuation is created. This will allow users to quickly learn the safe practices related to component management in flow scripts.

The question then becomes: does anyone envision real-world scenarios in which stateful components *are* needed across continuation boundaries? Or can we *always* formulate our flow so that we don't need to keep component state across continuations? (for example, database connections can be acquired/released as needed precisely because they're pooled). On a separate thread, if *all* acquired components *must* be released prior to creating a continuation... wouldn't it make sense for the FOM implementation to automagically release them??

How about defining a FlowSafe interface (contains no state and can be released/looked up transparently), and maybe a FlowSerializable interface (has a way that the state can be stored into the continuation and then restored, all transparently? So you would have to consciously code your components to use either of these interfaces, otherwise you'll have to manually release them before creating a continuation.