On 30-Jul-05 01:54:44 Maurizio Lotauro wrote:
On 28-Jul-05 08:34:58 Francois Piette wrote:
Do you want that the data passed to OnDocData is decompressed?
Yes I do.
Are you really sure? Ok Ok, I'll try to do it :-)
Done.
Now I have some points that I would like to discuss.
a) Exception in
Xavier, have you any reason to assign to FLastResponse?
No important reason
Xavier
--
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
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
Scrive Francois Piette [EMAIL PROTECTED]:
[...]
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.
RcvdStream is not the only way to get data from the
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.
RcvdStream is not the only way to get data from the component. Some (many
?)
applications sue
OnDocData
Scrive Francois PIETTE [EMAIL PROTECTED]:
RcvdStream is not the only way to get data from the component. Some (many
?)
applications sue
OnDocData event to get data on the fly.
In that case the decompression should be made completly by the
application, or
should we add some
On 26-Jul-05 20:37:54 Xavier Le Bris wrote:
Hello,
Hello,
[...]
FGzTime is necessary, not for me, but for anyone who wants to choose the
best compression level/time ratio.
I think that this is the job for a test application, not for the
component. You can use OnBeforeHeaderSend and OnDocEnd.
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
On 24-Jul-05 12:01:55 Xavier Le Bris wrote:
Hello,
A contribution to compression with gzip and some answers to Maurizio's
questions :
It is a good idea to put the whole stuff in another unit.
a/ The site 'http://www.pipeboost.com/' works today for me in T_HttpCliGz.
If not, check if zlib.dll
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
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
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,
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.
b) the RcvdStream must contain what effectly received from the server
or the decoded version? In the second case,
On 11-Jul-05 19:23:20 Francois PIETTE wrote:
Welcome back Francois :-)
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
14 matches
Mail list logo
