> I don't think that use RcvdStream for receiving compressed data is a > good idea because it will be more delicate to cleanup. Moreover it is > possible that more than one encoding are applied to the body and in > this case the situation will be even worse, not to mention the case > of on the fly decoding. > In my propose the RcvdStream will contain only the uncompressed data. > And about the RcvdCount, I think that it is better if it still > contain the byte effectly received. Changing it could mess up > existing code.
We already talked about RcvdCount. 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 ! > 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. 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. -- [EMAIL PROTECTED] http://www.overbyte.be -- 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
