It seems like every time I read or hear about Seam Gavin is going on about how most web applications don't support multi-tasking and how Seam kicks ass because it does. What this boils down to is the fact that Seam doesn't go chucking everything in session, so you can pop open a second window and have two windows in the same session that don't clobber each other.

But I have to say, I really don't like the way Seam manages this. Having tackled this problem many times, it's easy to see the solution Seam went with. Frankly it's not new, and I personally don't think it's the best solution. Effectively Seam traps the beginning of a new "conversation" and stores state for it in a scope that is walled off from other conversations. I worked on a framework that implemented this in 1999. We called it "Chapter Scope" because it usually covered a bunch of pages (get it?), and we eventually decided it wasn't the way to go. In both cases a conversation/chapter id needs to get passed back and forth in every request and the framework needs to be able to figure out when a new conversation begins.

The problem I have with this is that while it is multi-window safe, it's also overly restrictive. Example: try doing the following at both and the Seam DVD store demo:

  1. Open the homepage
  2. Search for something (anything)
  3. Shift/Cmd click on the next-page link to open a new window
  4. In the original window enter something new in the search box
  5. Page around in both windows

This, or course works seamlessly at amazon. But on the Seam DVD store demo you get bounced back to the homepage when you try to open the next page of search results in a new window. Why? Because the next-page link uses JavaScript to ensure that you don't open it in a new window. And it does that because then it would get confused because you'd have two windows open in the same conversation and things would go just as whacky as if you were storing things in session.

So basically Seam allows multi-window operation, but you can only fork windows in certain ways because Seam has to be able to figure out when a new conversation starts. This doesn't seem like the free-wheeling multi-tasking web that Gavin likes to talk about.

Compare this to the approach I've been using for years, and is now codified in the wizard support in Stripes. It may not look as shiny or have as many big words around it, but it's the same solution that amazon uses and it covers all the bases. You write hidden fields into each page containing the input (or necessary state) from the prior interaction; enough to tell the server what the right thing to do is. This way you can open up a new window anywhere, and the state gets "copied" by virtue of the way the browser works, and if the state changes in one window it doesn't affect any of the others. This can be a pain to do manually, but Stripes will do all this for you. So not only can you multi-task in an application built on Stripes, you can do it in more places than one build on Seam!