[hunchentoot-devel] Re: Current development

[Lars Rune Nøstdal]

Edi Weitz wrote:
> On Tue, 10 Jun 2008 11:23:44 +0200, Lars Rune Nøstdal <larsnostdal at gmail.com> wrote:
> 
>> But something I'm missing from HT is the ability to control the
>> stream or connection after this. SEND-HEADERS did not seem to work
>> as I needed because if I "collect" the stream returned from that
>> function for usage later, and let the request-thread it originated
>> from die it seems the old HT has been closing that stream which of
>> course causes problems when I later wanted to use the "collected"
>> streams.
> 
> The stream you get from SEND-HEADERS is only good for handling the
> current request, it is up to Hunchentoot what it does with this stream
> later on and it depends on what has been negotiated between the client
> and the server.  There are situations where the server must close the
> stream and there are situations where the server must re-use it and
> read the next request from it.  The server must also be able to switch
> chunking on and off between requests if needed.
> 
> So, if you're trying to "keep" the stream between requests, that won't
> work.

I am keeping it so I can respond to the current request - but to do so later, from a different thread. This might seem strange, I know, but it is useful here. x)

Think of it as a sort of "hanging" or waiting response on the server end, and there are many of them -- a lot, so one thread pr. client with a wait condition or something isn't going to work. The threads (connection-manager again) are to be fetched from a pool and they got to end up back in it when there isn't any more "real" work to do.

I tried to save a closure with the stream (returned from send-headers) in it and I was intending to call it later when the server has something it wants to push to that client. I'd let the thread that read the headers of the request originally "die out" opening a bit more room for other clients.

..this might be too different from what HT currently does, or is. So maybe an option for me would be to add something that dispatches to this behavior internally (based on GET/POST parameters, I think) in HT. How close are you guys to finishing work on the branch by the way? I'm guessing it would make sense for me to work vs. the branch now.

Comet is used to push data from the server to the client like this by the way. Think of stock data in real time; using JS to update the HTML elements in the DOM on the client.

> With respect to this, the old and the new Hunchentoot should behave
> the same.  If they're not, that's probably an error.

Ok.

>> In the new HT this doesn't seem to happen (I think?), but the stream
>> is of a binary type. I was wondering -- how do I send text to this
>> stream?
> 
> Yes, this is new.  The rationale is that if you want maximum
> convenience and protection from errors, you just send content to
> Hunchentoot and let it take care of sending the right data to the
> client.  If you request a stream, you're likely doing this for
> performance reasons or because you want to do something special, so it
> seems right to give you the "raw" binary stream.  If you want to send
> text to this stream, wrap it with a flexi stream, see for example
> stream-direct-utf-8 here:
> 
>   http://bknr.net/trac/browser/trunk/thirdparty/hunchentoot/test/test.lisp

Thanks!

-- 
Lars Rune Nøstdal
http://nostdal.org/