Are continuations a key feature in Seaside?

Question

I'm trying to get up to speed on Smalltalk / Seaside. According to Wikipedia, "Seaside is a continuation-based web application framework". Coming from a Java background I'm not very familiar with continuations.

After some reading I understand continuations are used for maintaining state, whereby a snapshot of a process is saved and can be resumed later (analogous putting Windows in hibernate mode).

This is most relevant to Seaside in relation to use of the "back" button? Using code blocks and "callbacks" is NOT the same as using continuations?

I'm also trying to gauge the current importance of actually using continuations in Seaside. I'm confused because many online references to Seaside mention continuations as a key and defining feature. However, I've also found a number of articles that mention the use of continuations in Seaside is not as commonly used and not actually a key feature.

Many thanks for any helpful input in setting me straight with this!

Menhaden

Answer 1

Initially Seaside used continuations to model the flow between pages and to enable the back button. This is no longer true for Seaside 3.0: continuations are completely optional. If you want to use the call: and answer: functionality you can load the package Seaside-Flow. Otherwise the Seaside application is continuation free.

Either way, as a web application developer, you never see (or saw) the continuations. They are an implementation detail that is well encapsulated in the Seaside web framework.

Update: In Seaside 3.0 state is managed by storing a special object per request. This object remembers the application state at that point in time. Should the user come back the object knows how to restore and resume with the previous state. In that regard, this object behaves like a continuation (the class is called WASessionContinuation), but its implementation is very different. It does not snapshot the execution stack, but only specific parts of the application state (that's why less memory is consumed). Also it does not jump somewhere into the code like a continuation would, but instead implements the necessary resumption logic as part of the template method WASessionContinuation>>#handleRequest (that's why it is faster).

Vermont

thanks for your reply. if continuations were used to manage state but are not longer used by default in Seaside 3.0 then how is state managed differently now? – Menhaden

@Jusin: Good follow-up question. For space reasons I added my answer to the original answer. – Vermont

thanks for adding more info. one last question (i hope). in a typical callback (as illustrated here seaside.st/documentation/maintaining-state) where "after an action callback finishes, the same component instance gets redisplayed". Seaside is maintaining the state of the instance variables between requests. does this relate at all to continuations or in Seaside 3.0 to the behavior that is like continuations but implemented differently? – Menhaden

@Justin: A continuation typically just captures the state of the execution stack. The state of the components (and the other backtracked objects) is kept in a WASnapshot instance that is cached together with the WASessionContinuation (or previously together with the real WAContinuation). – Vermont

Answer 2

Continuations are a key feature to show that it is possible to do web programming using the right abstractions. That allows Seaside to attract smart developers, who like developing at the right abstraction level, with the productivity gains following from that. But it doesn't mean that it is the right abstraction for your web application, nor that it is needed in Seaside.

Skillful