Hello,
I finally get some time to check the changes proposed to handle the
gzip content encoding.
First I think that it should be better not to add specific gzip
handling but a generic class to handle the content encoding, using a
registration machanism for each encoding, like what happen with
TG
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 is well loaded.
Maurizio, if you want, I can s
PROTECTED]
http://www.overbyte.be
- Original Message -
From: "Maurizio Lotauro" <[EMAIL PROTECTED]>
To:
Sent: Friday, July 01, 2005 12:00 AM
Subject: [twsocket] Adding gzip to HttpCli
Hello,
I finally get some time to check the changes proposed to handle the
gzip
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
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, inde
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 documen
ng"
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:
>
&g
Scrive Francois Piette <[EMAIL PROTECTED]>:
> > 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
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.
> 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
RcvdStream and RcvdCount, I let François suggest the strategy.
Regards
Xavier
- Original Message -
From: "Maurizio Lotauro" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Tuesday, July 26, 2005 3:32 AM
Subject: Re: [twsocket] Adding gzip to HttpCli
On 24
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.
>RcvdCo
> >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) f
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 th
>> > 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 s
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
> > s
>> >> 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 support for t
On 27-Jul-05 18:59:30 Francois PIETTE wrote:
[...]
>>> If decompression is done on the fly (streaming, we already talked about
>>> this), then nothing special is required.
>>
>> The decompression will be made only if RcvdStream is assigned.
>That is not needed. The decompression can be made alwa
> Do you want that the data passed to OnDocData is decompressed?
Yes I do.
> This could eventually be done only if the class that make the
> decompression supports "on the fly", or better if all classes neded
> to decompress the body suport it.
If the class doesn't support "on the fly" decompres
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 :-)
>> This could eventually be done only if the class that make the
>> decompression supports "on the fly", or better if all c
> 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
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) Exceptio
23 matches
Mail list logo
