Before start, I get your answer from the archive of this ML because it seems that my ISP has lost a whole day of emails :(
On 12-Jul-05 02:41:45 Francois PIETTE wrote: >>>> a) where is the best place to decode the received stream? Xavier do >>>> this in the GetBodyLineNext when the end of document is reached. >> >>>I think decoding should be done on the fly. >> >> What do you mean? Data should be decoded during the receiving, i.e. >> without having first the whole body? >Yes, indeed. Most compressions, including gzio, are streaming type. So it is >easy to decode them on the fly. >Of course if some compression is not streamable, then receiving the whole >thing then decompressing is OK. So we should consider both. But there is a potential problem. The RFC stated that more that one encoding can be applied to the body. We can have then a mixed situation. BTW the Xavier proposal make the decode at the end. I think that initially making the decode of the whole thing will be easier to implement, and in a second time we can add the streaming capability. [...] >>>Coded version should remains purely internal to the component. Should that >>>coded version be of some interest (but why ?), then maybe an event or a >>>new >>>property could give access to it. >> >> The only reason that I see is for debug, in particular for the >> decoding routines. >In the component, where received data is written to RcvdStream, it must be >written to the decompression stream, and then the decoding stream is read to >get decompressed data (if any: you don't always have decompressed data each >time you write compressed data) and written to RcvdStream where it is >available for the application. >RcvdCount, used for determining the end of document, must represent the >compressed byte count. >Maybe be the component has to use another variable for that purpose >(determining when document is complete) and still expose the decompressed >byte count in RcvdCount property. Doing so will make decompression >completely [well, mostly] transparent to applications. I see a potential >problem: RcvdCount is used by application to update progress bar, so it must >be compressed byte count. But other applications use it to know how many >bytes to process, so it must be the decompressed byte count. We can't have >both ! So a choice must be made. I don't know what the best is. Any opinion >? I never used RcvdCount then one choice or the other is the same for me. But I see a bigger problem. FRcvdStream and FRcvdCount are declared protected (as everything not declared public or published) and then is it possible that components inherited from THttpCli have used these variables. 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
