[Seaside] VisualWorks + WebServers
janko.mivsek at eranova.si
Wed Jul 25 10:43:46 UTC 2007
Philippe Marschall wrote:
> 2007/7/25, Janko Mivšek <janko.mivsek at eranova.si>:
>> 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.
> They way I understand Swazoo it does not handle encoding. This means
> someone who uses Swazoo will have to implement encoding on every
> platform unless the wants to deal with bytearrays instead of strings.
Maybe we can think of adding encoding to Sport portability layer so that
encoding will be portable among dialects. Web frameworks will then have
a portable way to deal with that.
Aida/Web for instance has just two methods, which are used elsewhere for
codepage conversions: AIDASite class convert:fromCodepage: and
convert:toCodepage: . All I needed to do while porting Aida to Squeak
was to change those two methods. Those two methods can be just put in Sport.
Seasiders can introduce something like that too and you'll solve
codepage problems once for ever!
>> 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
>> > 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
>> > 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
>> > sorry for that, but I have to go with the server that the consensus
>> > 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
>> > 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
Smalltalk Web Application Server
More information about the Seaside