VisualWorks + WebServers

Janko,

Thanks for detailed comments. Like I said in one of my earlier comments, however, for VisualWorks users like myself who already use wtk for other things it makes total sense to use the same underlying broker, commercial support reasons included. I have tried to raise the problem of Utf8 support here a couple of times in the past and didn't get very far until I patched it myself in a crude way, whereas I had no such issues with tiny http on VisualWorks at all and would not have moved to swazoo if it wasn't tied in to all other misc crap. Also, as far as performance, I expect opentalk brokers to be just as fast given the very little overhead they carry, so let's not imply anything yet until the code can be exercised in the wild.

Also, how does your work on swazoo relate to the work Bruce is doing with sport and hyper? Shouldn't that be the focus? To an external developer like myself it seems there are two completely separate efforts going on based off the same codebase.

Cheers!

-Boris
(Sent from a BlackBerry)

----- Original Message -----
From: [hidden email] <[hidden email]>
To: Seaside - general discussion <[hidden email]>
Sent: Wed Jul 25 01:15:33 2007
Subject: Re: [Seaside] VisualWorks + WebServers

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
Janko

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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside