> 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.
Two compression applied one after the other or one compression for a part of the document and another one for the remaining part ? In either case, I don't understand how it could work except if the document is in MIME format and compression apply to MIME parts. Thta is a completly different problem. > 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. I think the code would be completely different. It's writing it twice. Streaming is very interesting for example when downloading images or sound and start displaying or playing before the end of document is here. And this apply also in basic document type where display can be done as the document is comming. -- [EMAIL PROTECTED] http://www.overbyte.be ----- Original Message ----- From: "Maurizio Lotauro" <[EMAIL PROTECTED]> To: "ICS support mailing" <email@example.com> Sent: Friday, July 15, 2005 1:55 AM Subject: Re: [twsocket] Adding gzip to HttpCli > 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 > -- 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