Web Transactions With Continuations

(The word 'transaction' in the title suggests the AcIdic kind of transaction rather than the things under discussion here. Move the content to, say, WebInteractionsWithContinuations? or even WebSessionsWithContinuations??)

"For example web transactions can be viewed as suspension and resumption of continuations, which makes handling state on the web a lot easier." Please explain?

For a practical example of this in the SmalltalkLanguage, see SeasideFramework at http://www.seaside.st/. It uses continuations to bring page-flow semantics closer to a subroutine call - rather than linking or redirecting to the next page, which is essentially a GOTO, you call it, and it can return a value. This is done by suspending the current continuation, presenting the next page to the user, and at some later point (say, on the submit of a form) resuming the stored continuation. The really nifty part is that you can use the browser back button to submit that form multiple times, causing the subroutine call to return multiple times, with different values each time. Here's the sample included with SeasideFramework in Smalltalk.

  WAStoreTask>>go
| shipping billing creditCard |
cart := WAStoreCart new.
self isolate:
[[self fillCart.
self confirmContentsOfCart]
whileFalse].
self isolate:
[shipping := self getShippingAddress.
billing := (self useAsBillingAddress: shipping)
ifFalse: [self getBillingAddress]
ifTrue: [shipping].
creditCard := self getPaymentInfo.
self shipTo: shipping billTo: billing payWith: creditCard].
self displayConfirmation.

To elaborate on this, suppose the function confirmation-page/wait showed a page asking Ok / Continue, the function send/wait sent some form HTML and returns the params specified by the form, and the function extract-param extracted a specific param from those params, it allows you to program something like this:

 (show-html 
   "<html blah... The age you specified was " 
     (let loop ()
       (let ((entered-age (extract-param "age" (send/wait "<html blah <form blah .. Enter your age: ..."))))
         (if (> entered-age 100) 
           (if (confirmation-page/wait "Thats very old! Are you sure?")
              entered-age
              (loop) ) ) ) )

Once you get past the brackets and the prefix notation, it's amazing how succinctly you can express what in normal ASP/JSP etc style programming is very tedious. - James

The upshot of all this is that your web application can be structured in a much more typical (for non-web applications) way, with long sequences of page views all specified in one contiguous piece of control flow logic, and you get transparent backtracking.

Another nice thing is that it gets you out of the business of managing a bunch of shared data in a global "session" name space, and trying to deal with all the possible combinations of users pressing the back button, duplicating windows, opening links in new windows, etc.

[The above example enforces a particular sequence of error corrections on the user, whereas what is most desirable (and universally implemented on major portals) is to flag multiple errors at once, and allow the user to fix them in any sequence they desire. This could perhaps be paraphrased as saying that fixing multiple form errors should be modeless.

Continuations aren't inherently thus limited, although I suppose that an example that showed the latter instead would be significantly more complex. Anyone care to show a more complex example that fixes that issue?]

In my opinion, the way around such issues is EventDrivenProgramming. Thus reduces the need to keep processes "open" between transactions. However, it generally requires declarative GUI models either on the server (mirroring client) and/or the client. Inter-transaction state is generally kept in a database or database-like thingy, but simple scalars can be put into "hidden fields" of the UI model. However, it still may not significantly simplify things such as Yes/No questions on web forms, unless perhaps "Yes" means restart/retrigger the event and "No" means cancel, which is often the case.

This seems like it would relate well to 'AbortRetryIgnore'-style ExceptionsWithContinuations, especially if one really wished to support transactions in web-services with callbacks that can ask for permissions, handle errors, and such.

CategoryContinuation