On Dec 16, 2007 1:51 AM, Bogdan Ciprian Pistol <[EMAIL PROTECTED]> wrote: > Hi all, > > On Dec 13, 2007 7:50 PM, Trustin Lee <[EMAIL PROTECTED]> wrote: > > 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. > > I wrote only the server part (the encoder), the server is accessed by > standard web browsers. :) > > This is how I see a client receiving chunked messages: > > The client receiving the chunked message can wait until the hole > chunked message is received (how the browsers are handling chunked > messages) > and then the decoder would pass the message as a normal HTTP message > to the application. > This assumes that for the application the message has a meaning as a > hole (all the chunked messages together), individual chunks are > meaningless. > > The client could also decode every chunked message as an individual > part of a stream of messages and the decoder will pass to the > application every chunked message. > This assumes that the application can handle every chunk individually > and every chunk has a meaning (it can be individually evaluated by the > application). > > The two ways of handling chunked messages should be configurable. An > application should manifest it's interest in a what way to handle the > received chunked messages.
Makes a lot of sense. We need to make it configurable and retain the current behavior unless it's configured differently from the default. > Tuure, why standard HTTP messages cannot be used for streaming? Why > chunked messages are more appropriate? > If you send chunk after chunk in the same HTTP response or if you send > multiple standard HTTP responses it is almost the same (a standard > HTTP message has just some optional additional headers and that first > status line). We could make our current class hierarchy more granular like the following: * HttpMessage ** HttpRequest - no getContent() *** MergedHttpRequest - getContent() here *** ChunkedHttpRequest - once written, encoder expects HttpChunks, other HttpRequest or disconnection. ** HttpResponse - no getContent() *** MergedHttpResponse - getContent() here *** ChunkedHttpResponse - once written, encoder expects HttpChunks, other HttpResponse or disconnection. * HttpChunk - getContent() here Most users will be OK with MergedHttpRequest and MergedHttpResponse and some people who wants to stream a big message will use ChunkedHttpRequest, ChunkedResponse and HttpChunk. Additionally, we won't need END_TOKEN because the encoder implementation can determine the end of the chunks easily. For decoding, if the decoder is configured for chunking, the decoder will produce ChunkedHttpRequest and HttpChunks or ChunkedHttpResponse and HttpChunks. If not configured for chunking, then just MergedHttpRequest or MergedHttpResponse will be produced, which is the default behavior. I am not sure about the class name prefix 'Merged' though. Any better name suggestion is appreciated. What do you think about this solution? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
