On 26-Jul-05 17:47:41 Francois PIETTE wrote: [...]
>We already talked about RcvdCount. Yes, but we haven't still get a conclusion :-) >I think I said that RcvdCount that a choice has to be made and Ithat I have >no defitive answer. The idea is to break as less as possible existing code. >RcvdCount is used for progress bar updating and should be compressed byte >count. It is also used to allocate storage (or similar use) for data and >should be decompressed data. Maybe for simplicity we should let RcvdCount be >the compressed byte count ? Really a question, the debate is open ! I doubt that RcvdCount could be used to allocate storage. The body data will be put into RcvdStream that is a stream, and normally a stream is able to allocate the storage itself. It could be useful if the size of the body is known in advance so the whole storage is allocated in one step, but eventually you have this information only with the content length and not from RcvdCount. And the content length is not always specified, not to mention the case when it is wrong. After all this considerations my conclusions are: - RcvdCount contains the count of bytes received from the server - ContentLength contains what specified in the header >> Similar question for ContentLength: should it contain what is >> specified in the header or the effective final length of the body? >The final length will not be known before everything is decompressed. Exactly. >ContentLength, IMO, should stay in sync with what the header says. A new >property could be added to have the decompressed content length. Not that >much useful as the user has RcvdStream.Size or can cumulate what he receive >in OnDocData. You red in my mind :-) Bye, Maurizio. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
