[Seaside] VisualWorks + WebServers

Michael Lucas-Smith mlucas-smith at cincom.com
Tue Jul 24 23:41:35 UTC 2007

I was wondering when this topic was going to come up and how exactly to 
put my 2c in. There was a sudden flourish of excitement about Swazoo 
that I didn't want to kill.

We're making Seaside in VisualWorks run on Opentalk-HTTP. This is the 
raw streaming http server code, the most modern we have. It's fast, 
scalable, solid and comes with no bells or whistles at all. You won't be 
loading in WebToolKit, TinyHttp, Swazoo or anything else, just 

Further to this, it'll come as the default configuration. You'll be able 
to continue using Swazoo or WebToolKit if you want, but if you load 
"Seaside", just like in Squeak, it'll load up fully configured with 
Opentalk-HTTP (or Komanche in Squeak) ready to run, out of the box.

The obvious win here is that new users don't have to scratch their heads 
trying to figure out what package or bundle they're meant to load. 
Fixing that is goal number one. The second obvious win here is 
performance.. the Opentalk-HTTP code is very efficient - and Martin 
Kobetic is continuing to improve on that every day. The third win here 
is the streaming capabilities, which don't seem to exist in Swazoo yet 
and do exist in WebToolKit but in a weird way. It'll be nice to have 
Async, Comet and ShoreComponents, etc, simply work out of the box 
without hassle.

For the majority of users, which HTTP server to use in VisualWorks will 
now be a complete non-issue. I know this blocks out Swazoo a bit and I'm 
sorry for that, but I have to go with the server that the consensus here 
in engineering feels is the best direction to go - and that is 

There are bigger plans afoot to move WebToolKit on to Opentalk-Wave 
which is built off Opentalk-HTTP. This would provide the basis for all 
three web frameworks in VisualWorks: Seaside, WebToolKit and VisualWave. 
Obvious that goal is a while off and I've got the team focusing on our 
primary framework first - Seaside.

The actual integration with Seaside is pretty minuscule. There are a 
couple of classes and a handful of extensions. It speaks volumes for 
Seaside's HTTP interface design that it's so easy to hook up.


Boris Popov wrote:
> Michael,
> Since you're now the lead for Cincom's Seaside efforts I was wondering
> if there's any intention to be able to run Seaside behind Tiny without
> all of session/site/resource management overhead. Perhaps a glue layer
> for HttpServerStreams is in order instead? I don't mind Swazoo, but it
> still seems a bit of overkill for what little is actually required by
> Seaside ;)
> Cheers!
> -Boris

More information about the Seaside mailing list