This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Keynote - Seaside with Avi Feed Title: Michael Lucas-Smith Feed URL: http://www.michaellucassmith.com/site.atom Feed Description: Smalltalk and my misinterpretations of life Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Michael Lucas-Smith

Avi was really animate on the stage and it was a great talk about Seaside and the general follies of web development in its current state.

Starts with a great quote from Jim - "I'm more of the mind that HTML based apps suck." Why bother doing this. Avi says the reason to bother is prevalence. Applets failed because they weren't the web - they were something else.

Server side can be a second chance, since Java is successful on the server but a failure on teh client side.

Avi said that lisp is a weird dialect of Smalltalk. Smalltalk and lisp is more productive than other languages. Use them as a competetive advantage.

On the web it doesn't matter what your application looks like - Squeak looks very weird. If ypou think web apps are weird to use - you should try writing them.

What is a web app - a collection of functions that take HTTP requests as input and produce HTTP responses as output. The response is probably a HTML document - rendered in your browser, etc, etc.

The web was designed to be stateless - but every application that deals with users is going to have state. How do you want to handle state? First example - GemStone/S Server <-> VisualWorks Client.

Because there is no state, all your information is shuttled back and forth between requests and responses until you finally get to the end. THis is awkward for a developer because you have to constantly think about marshalling. Web development is very similar to command line programs. Lots of time pulling stuff in .. do something small .. lots of time producing a new output.

Solution to this problem - a session. A session has a unique id. Only have to shuffle the id around. So the problem really isn't solved. You're still pretending you're stateless. The session is a global state holder.

Global state fails because of threading. Race conditions, contention, stuff will get overidden.

Avi's solution he likes better. Comes from a product called WebObjects - made by NeXT. Written in Objective-C. Every page you go to gets its own id so that if you re-visit a page, you're actually visiting a different page on the server.

Avi compares source code control in Smalltalk to files in Java with Web pages to ids mapping back to objects in the server. But this isn't far enough since we're in Smalltalk.

States the first problem, the next problem is coupling. Everything is fairly linear.. the page points you to the next place you're going to go. A always goes to B always goes to C. Page flow is rarely linear. There are lots of combinations you can execute in.

Avi's answer to solving the coupling problem is Continuations.

"Seaside is to most other Smalltalk web toolkits as Smalltalk is to most other OO languages, it's as simple as that." -- Cees de Groot.

Without Continuations you'd have to make a big link of pages that you go to. Except that this doesn't let you change directions on the fly. The resulting code looked a lot like lisp.

So to go better than this. Use blocks - give a block to figure out the next page to go to. The blocks version has all the state sitting there as a block parameter with scope. It's a good version because we get component reusability. Unfortunately - it's really yucky code with weird nesting.

But to get rid of blocks every where, we just want to use method calls. Using the continuations.. we can rewind the method because the user went back in pages and hit an action that they've possibly already hit. Just like the debugger can drop the stack back - so can the continuations engine.

Question: How does the state not conflict between continuations? a) We don't suspend the process.. we save a copy of the whole context stack - which will include all the local variables. Only instance variables would have conflicts.

The developer can isolate: a section of code so that once that block is complete, every continuation that occured inside the block expires immediately.

Question: If you go forward.. then go back and change something so something on the forwarded page may be invalid. You need a forward isolate. a) It'll handle it.

Lots of people wanting to see Avi go back and forth between pages and browser windows trying to catch him out as if he's hiding a card up his sleeve. a) If you don't hit submit, then hitting forward will lose your changes on the page you're on.

This demo session has used 100k roughly so far. Seaside is memory intensive. Trading memory for ease of use. There are apps that you cannot make that trade-off. Avi says 90% of web apps you're going to make, that trade-off is completely practical.

Question: When you copy the state, do the page objects get new id's? a) The id is for the particular continuation at this point, not for the pages. So yes, you get a new id each time you submit or hit a link.

Question: How do you load balance Seaside a) You have to have a load balancer that keeps a user on a particular server. Must keep them on the same server.

If you put out a new server - the old server has an old id so you can keep users working until their sessions expire and new sessions will use the new server.

Question: But it only works for temporary variables a) We'll get back to that.

Other benefits: Exception handling lets you backtrack when things go wrong and continue down the working path instead of the broken path. He has a debug link in his browser. A debugger pops up inside Squeak - the browser is waiting now. He proceeded his error and the next page comes up.

Back to the previous question. You can register objects that get backtracked. It makes a shallow copy of any object that you've registered as backtrackable. For example - a tab widgets selected tab index.

Question: Other sesssions trampling on ecah others data? a) Guaranteed not to be in the same session between threads. Developers just need to deal with it and make sure they're not introducing that sort of bug.

Question: Show us the continuations implementation a) Okay.

Main continuation class is missing a comment.. big red error message THIS CLASS HAS NO COMMENT!

Continuations is 10 lines of code.

Question: What about ensure block's a) They get nasty. Termination of a closure will not call the ensure.... or will it? He's not sure and you have to be careful about it. Don't have your ensure block go across multiple continuations.

Point: Scheme has continuations. CommonLisp has no continuations because it has ensure

Question: Can you serialize a continuation? a) Yes. You could, but it might be tricky. Useful for fail-over. The server goes down but you've put the continuations on disk.. you can bring up another server and everything continues as-is. Bookmarking too.. store every continuation and any page you bookmark you can come back to any time.

I wonder if SRP would fit in there?

Good reuse of pages.. but what about reuse between pages? Lots of problems because you get conflicting names in the typical way of doing web development.

Use callbacks. Don't name things on the page. Nice and simple, all ids are generated by the Seaside engine and they're matched up on submit.

Generate your html using code and use CSS to style it so that it looks like your application. This is something that we totally agree with in WithStyle as well. Simple XML with styling in CSS is great.

Question: Where does the CSS live? a) Evert component in Seaside has a method called 'style' that lets each component return its own css.

Question: What if there are lots and lots of actions on a page? a) Don't use call: use the callback stuff instead so that its event based.

Question: Is it ported to other dialects? a) There is a port to VisualWorks - current. Won't work in VA because you can't copy the stack. Dolphin does work but is not up to date. Smalltalk/X has the same problem as VA.

Question: How is the documentation going? a) Horribly. Lazily initialised documentation