[Seaside] VisualWorks + WebServers

Martin Kobetic mkobetic at cincom.com
Wed Jul 25 18:45:57 UTC 2007

>> My next obvious question is, when can I take this for a test drive? ;)
>Well Martin is getting close to being happy with it. He has it running 
>against base seaside without a problem - in fact, it runs faster and can 
>do some things that you couldn't do before - such as file upload test 
>didn't run.

It will probably take a bit more time to be really confident about it, but it seems to be working at this point. At least as far as I can say clicking through the Seaside test pages and visually comparing results with the WTK and Squeak versions.

The SeasideForOpentalk (SfO) package is now automatically replicated into the public repository, so new versions are available as they come. You'll need a recent version of Opentalk-HTTP as well, the parcel from 7.5 or even a recent build won't do (not until first version of SeasideForOpentalk makes it into a build). There is a short package comment showing how to create a server and few other useful bits. This was all tested against Seaside 2.7. It breaks with 2.8 at least on the Status being Integer instead of String issue, possibly elsewhere too. We're focusing on 2.7 at the moment.

As for the current status. The Opentalk server infrastructure, connection management etc, has been used quite a bit, it's been the basis of the newer Wave servers as well. The HTTP layer itself was only used for deployment of WebServices so far, so I suspect it didn't get as heavy beating as some Web applications get. Moreover we've recently overhauled the entire HTTP layer to make it "stream", which provides same really nice advantages, but it's still fairly fresh code nevertheless (released with VW 7.5). So we have yet to see if we're really done with that. However you can already take advantage of some of the improvements. For example the SfO package includes an example WAExternalFileLibrary which allows fetching external files from a Seaside server. The HTTP layer allows to stream the file directly from the disk into the socket, so getting a 15M image file was nearly instant in my tests running the browser and the server on the same host. For uploads the HTTP layer automa
tically streams message parts designated 'content-disposition:attachment' directly into files, however in the Upload test the file gets packaged as 'form-data' instead (at least by Firefox) so it ends up in memory instead. So we'll have to figure out how to control the decision process for which parts end up in files and which ones in memory. But it's really more an API design issue, technically the layer is ready to stream anything anywhere.

On that note I'd like to mention one change that I felt compelled to make. The WAFile class is designed to hold onto its contents as an internal collection (ByteArray, String, whatever). I added a subclass WAFileStream with the same API allowing to hold onto it as a stream. That still allows using purely internal stream, but opens up the possibility to use an external stream as well. This is obviously aimed at being able to stream contents of a file straight from the socket to the disk as the request is being parsed and then provide the WAFile object on top of the new external stream. Would this kind of change be something of interest ? Maybe for the ongoing 2.8 development effort ?

Finally, I should say that we have yet to address what's referred to as "streaming" in the web-app space. To be honest it's still not quite clear to me what specifically it means at the HTTP level. I've heard it being described as the ability of the application code to write directly into the outgoing socket stream, but that still seems to be just an optimization more than a functional requirement to me. I even ran the SeasideAsync tests with SfO and they still seemed to work, even though they supposedly must have the "streaming" capability. I'm told to try Comet next. Anyway, the point is there might be a limitation in SfO that I don't quite grasp yet, so don't be surprised if you run into it :-).

That's all I can think of that might be of interest at this point. Of course we'd welcome any feedback we get.



More information about the Seaside mailing list