[Seaside] VisualWorks + WebServers

Janko Mivšek janko.mivsek at eranova.si
Wed Jul 25 08:15:33 UTC 2007

Well, Swazoo will go on regardless of Cincom decisions, to which you 
have all right of course.

Main goal of Swazoo is portability, portability and once again 
portability. Swazoo is currently running on 3 dialects and will soon on 
another one, so everyone developing a web framework with portability in 
mind should think deeply of which web server to support by default. And 
supporting Swazoo means not having portability problems everytime a new 
version of framework is out.

Another goal is simplicity (even that most of users currently complain 
just of that). And here I'm not quite sure that Cincom solution will be 
simpler to an average user. It is not to me, but knowing Swazoo in depth 
I'm of course a bit biased here.

Swazoo just looks complex but actually it isn't. I would say that this 
is just a matter of "encapsulation" of complexity, to say in OO terms. 
That is, visible and usable API should be simple and that's what 
forthcoming Swazoo is addressing in depth. More meaningful package 
organization, complex parts "hidden", less used and demo stuff out in 
Examples package... I also have a plan to simplify unnecessary complex 
Resource framework. But for anyone using it just up to Sites, a bit 
better docs will help again. There is also an effort on the way with 
documentation on its own website http://www.swazoo.org.There is a FAQ 
growing, There is a simple example how to make your own web resource. 
Soon an Administration guide is coming.

Third goal is performance. Swazoo is meant for a production web server, 
not only a testing one! It is already capable of running most web sites 
except really big ones. Also 2.0 supports input streaming (for file 
uploads, since yesterday!) and can also achieve 100MB/sec of output 
throughput when serving content from memory (on VW). Output streaming is 
also planned, probably in next days already.

Fourth goal is a web site hosting. Swazoo can serve virtual websites, 
that is, more sites on the same ip/port. So it is ideal for hosting many 
websites from the same image. For instance, currently I'm running 34 
websites in one image on my collocated server. About 1/5 of them are 
public web sites, others are hosted intranets.

To conclude, I urge Seasiders to choose Swazoo as a default web server 
for reasons above, especially because of portability and simplicity. But 
of course every vendor have a freedom to go its own way.

Best regards

Michael Lucas-Smith wrote:
> 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 
> Opentalk-HTTP.
> 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 
> Opentalk-HTTP.
> 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.
> Cheers,
> Michael
> 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
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Janko Mivšek
Smalltalk Web Application Server

More information about the Seaside mailing list