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. 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). Bogdan
