The general idea sounds good to me. However, it is possible to simplify it some. Define the interface as "the module will return a stream containing the data". Thus Comanche only needs to do #next and #next: and #atEnd, and can ignore the implementation of the stream. Then, for cases where a regular FileStream or ReadStream is not good enough, add a special kind of stream as you describe. By the way, Unix calls these kind of streams "pipes" or "fifos". Also by the way, you might consider enforcing that the header is generated completely by the module before it passes anything to the I/O part of Comanche. This shouldn't be a big performance loss (is any header really all that big?), and it allows you to provide convenience routines like #headerAt:put:. Furhermore, the status code would no longer have to be the first thing that you "respond". So if an error happens in the middle of processing, it would be easier to change the status code to some sort of error. Lex Bolot Kerimbaev <[EMAIL PROTECTED]> wrote: > Please comment on this (and send code if you already have it): > > There will be a WorkInProgressStream (WIPStream :). > A module creates a WIPStream, returns it (so that it can start serving), > and continues writing to it (as if writing directly to the socket). When > done, it just closes the WIPStream (probably means two threads). > > This could also work very well for writing a proxy server with caching. > > bolot > > P.S. Of course, you have an option of writing directly to the socket > stream, but then you also have an option of writing programs in assembly > or java.
