[Seaside] VisualWorks + WebServers
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
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:
> 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 ;)
More information about the Seaside