Hi folks, It seems like we now have some reasonable approaches on streaming large object now. I think all of them are valid, but I also would like you to think about receiving a large object. We need to resolve both encoding and decoding and the resolution should be symmetric so that it's easy to learn. Consequently, Dave's idea is providing some clue to improve the ideas of Tuure and Bogdan. It would be really exciting to see the best combination of the three ideas via cooperation.
Cheers, Trustin On Dec 13, 2007 3:16 PM, Bogdan Ciprian Pistol <[EMAIL PROTECTED]> wrote: > On Dec 12, 2007 4:19 AM, Tuure Laurinolli <[EMAIL PROTECTED]> wrote: > > Description of my encoder: > > > > ChunkedHttpResponseEncoder first expects an HttpResponse, and if the > > HttpResponse has Transfer-encoding: chunked set, switches to expecting > > HttpChunks instead. HttpChunks are simply containers for IoBuffers, and > > are simply written to the Iosession, prefixed with the appropriate chunk > > header. The response is terminated with a special END_TOKEN objec. When > > the encoder receives an END_TOKEN, it switches back to expecting > > HttpResponses. > > > > If the encoder receives an inappropriate object for its current state > > (END_TOKEN or HttpChunk when expecting HttpResponse, or HttpResponse > > when expecting HttpChunk or END_TOKEN, it throws an exception). > > > > Tuure Laurinolli > > > > I wrote several weeks ago an encoder, named HttpEncoder, that supports > standard HTTP and chunked HTTP messages (among others :) ). > It can handle ChunkedHttpMessage or HttpMessage classes. > So when you send a HttpMessage then it just sends that message, if you > send a ChunkedHttpMessage it uses ChunkedHttpMessage.isFirstChunk( ) > to handle the chunked protocol correctly. > The last chunk is not a token but an empty ChunkedHttpMessage (with a > null body), and when HttpEncoder sends this empty last chunk it is as > the HTTP specification says that the last chunked should be a zero > body size chunk. > > It is the ChunkedHttpMessage that keeps its state, whether it's the > first message or not, if the encoder would do this then I guess that > you couldn't simultaneously send standard HTTP and chunked HTTP with > the same encoder (when multiple sessions are using the same encoder), > if you use different encoders then I guess you could send them > simultaneously. > > Bogdan > -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
