go back to old versions.
Dan
- Original Message -
From: "Maurizio Lotauro" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Saturday, November 26, 2005 12:00 AM
Subject: Re: [twsocket] HTTP compression
> On 25-Nov-05 10:03:07 Dan wrote:
>
> [...]
&g
On 25-Nov-05 10:03:07 Dan wrote:
[...]
>Has Francois considered using CVS or something similar for ICS? Could come
>in very handy, you could maintain the normal and SSL branches and could
>merge fixes across both.
The standard ICS and SSL version share the same code. The specific
SSL parts are
- Original Message -
From: "Angus Robertson - Magenta Systems Ltd" <[EMAIL PROTECTED]>
To:
Sent: Friday, November 25, 2005 12:52 AM
Subject: Re: [twsocket] HTTP compression
>> Do you mean latest release, ICS beta or ICS-SSL?
>
> They are all the same code
> Is is strange to me how the presence of an unnecessary header can
> cause this behaviour. I'll check.
It could be something got confused when the HEAD command did not return
any data.
> > It all falls over horribly if the DLL is missing,
> > life is too short for DLL hell.
This turned out t
Scrive Angus Robertson - Magenta Systems Ltd <[EMAIL PROTECTED]>:
> > Do you mean latest release, ICS beta or ICS-SSL?
>
> They are all the same code. Unfortunately none of the recent developers
> have added dates to the code which means version control is very
> painful, but httpprot.pas was
> Do you mean latest release, ICS beta or ICS-SSL?
They are all the same code. Unfortunately none of the recent developers
have added dates to the code which means version control is very
painful, but httpprot.pas was dated 19th November, so recent.
It include a large number of undocumented NT
On 24-Nov-05 21:05:00 Angus Robertson - Magenta Systems Ltd wrote:
>I've merged your HttpProt changes into the latest version, and added
>the LocationChangeMaxCount feature to prevent endless relocation looping.
Do you mean latest release, ICS beta or ICS-SSL?
>The component is backward compatib
try and change the code tomorrow.
Angus
Original Message ----
*Subject:* Re: [twsocket] HTTP compression
*From:* Maurizio Lotauro <[EMAIL PROTECTED]>
*To:* ICS support mailing
*Date:* Tue, 22 Nov 2005 17:11:01 +0100
Scrive Angus Robertson - Magenta Systems Ltd <[EMAIL PROT
- Original Message -
From: "Maurizio Lotauro" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Tuesday, November 22, 2005 6:15 PM
Subject: Re: [twsocket] HTTP compression
> Scrive Fastream Technologies <[EMAIL PROTECTED]>:
>
> [...]
>
&g
Scrive Fastream Technologies <[EMAIL PROTECTED]>:
[...]
> The server then starts compression (deflate works by packet-by-packet way)
I see that some ftp program can download a .gz version of a file. This is a
different think, right?
Bye, Maurizio.
---
Scrive Angus Robertson - Magenta Systems Ltd <[EMAIL PROTECTED]>:
[...]
> I'm sure there are good reasons for all the work you did, I've just not
> yet found the demo application or readme. But I will at least try it
> later this week.
You must use the content of HttpContCod.zip that is in t
y!
I would give you my code but it's in C++.
Thanks,
SZ
- Original Message -
From: "Angus Robertson - Magenta Systems Ltd" <[EMAIL PROTECTED]>
To:
Sent: Monday, November 21, 2005 5:55 PM
Subject: Re: [twsocket] HTTP compression
>> > FYI, in FTP servers,
> To enable the gzip (or any other encoding) "actually" the developer
> must
> include one unit in the uses of one unit of the project.
> Too complicated?
Really don't know yet, I'm trying to unfathom the six extra source files
that this simple decompression needs, and decide whether it will wor
On 21-Nov-05 12:15:00 Angus Robertson - Magenta Systems Ltd wrote:
[...]
>If the new component needs external code adding to actually decompress a
>page, we are effectively no further forward than several years ago, and
>I'd just ignore any new attempt to add compression and use my old code,
>pro
> > FYI, in FTP servers, Mode Z is used for ZLib'ed (deflate)
> > transfers.
> One question could be: should the client automatically decormpress
> the downloaded file or it should be done by the application?
Compression is transparent to the user when Mode Z is used, the client
sees an uncompr
- Original Message -
From: "Maurizio Lotauro" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Monday, November 21, 2005 5:14 PM
Subject: Re: [twsocket] HTTP compression
> Scrive Fastream Technologies <[EMAIL PROTECTED]>:
>
>> - Origi
Scrive Guillaume MAISON <[EMAIL PROTECTED]>:
[...]
> i do agree to say that using zlib or any other compression method has
> more its place within a demo (why not write a special demo for using
> compression with http based upon any of the actual demo, but named
> specifically HttpCompression
Scrive Angus Robertson - Magenta Systems Ltd <[EMAIL PROTECTED]>:
> > I suggest that the compression part (i.e the one that implement the
> > gzip using the dll) should not be included in the library (I mean the
> > ICS package, not the distrbuted zip) but as demo or similar. Then it
> > is a choo
Scrive Fastream Technologies <[EMAIL PROTECTED]>:
> - Original Message -
> From: "Francois Piette" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Monday, November 21, 2005 9:42 AM
> Subject: Re: [twsocket] HTTP compression
>
&g
> So essentially what you ask is that the default implementation use
> C-Obj ZLib delivered with Delphi.
Assuming it works technically, yes. Then the component works
immediately with each different developer needing to implement ZLIB on
their own, or search the demos for code to borrow.
Ang
Angus Robertson - Magenta Systems Ltd" <[EMAIL PROTECTED]>
To:
Sent: Monday, November 21, 2005 10:51 AM
Subject: Re: [twsocket] HTTP compression
> > I suggest that the compression part (i.e the one that implement the
> > gzip using the dll) should not be included in the library
> there i don't agree with you. if you consider ICS, it's almost VCL
> free. it shouldn't be more dependant on any VCL component.
VCL, RTL, it's all the same thing, components delivered as standard with
Delphi. ICS is not VCL/RTL free, it uses classes with strings lists,
streams, etc. ZLIB is
Angus Robertson - Magenta Systems Ltd a écrit :
>>I suggest that the compression part (i.e the one that implement the
>>gzip using the dll) should not be included in the library (I mean the
>>ICS package, not the distrbuted zip) but as demo or similar. Then it
>>is a choose of the developer if incl
> I don't have the knowledge to understand who is right (actually I
> don't use Mime), but I have the same opinion of you: if something is
> wrong it must be corrected even if this mean that it is no more
> backward compatible.
> But at the same time the developer must be warned about a change
> li
> I suggest that the compression part (i.e the one that implement the
> gzip using the dll) should not be included in the library (I mean the
> ICS package, not the distrbuted zip) but as demo or similar. Then it
> is a choose of the developer if include it (or another
> implementation) in the appl
- Original Message -
From: "Francois Piette" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Monday, November 21, 2005 9:42 AM
Subject: Re: [twsocket] HTTP compression
>> I don't know the FTP component, maybe what I proposed can be
>> m
> I don't know the FTP component, maybe what I proposed can be
> modified to share some code for support both protocols?
Probably yes.
To be honnest, I have no idea about how FTP implement compression. I guess it
is just a matter of a
command sent on the control channel before the actual transfer
On 20-Nov-05 18:56:18 Piotr Da³ek wrote:
[...]
>As I told before, it is not possible to leave it backward-compatible since
>original TMimeDec marks end of part at any boundary - it sees ending and
>starting boundary as one thing - resulting in phantom (empty) parts and
>nested parts corruption. B
On 20-Nov-05 14:59:00 Angus Robertson - Magenta Systems Ltd wrote:
[...]
>The Borland VCL uses OBJ files for it's TCustomZlibStream class in
>Delphi 7 and later (and for JPEG images), so if it's good enough for
>them, it should be good enough for us. That's what I'll try and use,
>although I mig
On 20-Nov-05 10:55:56 Francois PIETTE wrote:
[...]
>I wonder if we shouldn't simply push the compression code into that beta.
>This is probably the only way to have people really testing it (well beside
>pushing it into the release).
>Anyone having any opinion about that ?
I fully agree with yo
On 20-Nov-05 12:25:37 Francois PIETTE wrote:
[...]
>As the compression is encapsulated in the HttpProt component, one could use
>anything it likes for actual compression library with minimal effort. It is
>not mandatory to use any DLL. My first idea was to validate the code using
>any compression
On 20-Nov-05 12:10:00 Angus Robertson - Magenta Systems Ltd wrote:
[...]
>I'm vaguely planning on adding ZLIB compression to the FTP client and
>server (which FileZilla supports) and that will need a proper ZLIB
>components using C OBJ files, once that is done HttpProt can use the
>same stuff.
I
Hello!
> released, effectively alpha testing. Unfortunately such alpha testing
> does not seem to be done by all ICS developers, so things get broken.
> Of the two pending beta components, I found MimeDec to cause one of my
> applications to no longer decode the last attachment part of email,
>> I'm not too happy with c-obj files. I would prefer one of the many
>> Delphi ports.
>
> Why?
Because you can't be sure the code will still be OK to link with the next
compiler version.
> The Borland VCL uses OBJ files for it's TCustomZlibStream class in
> Delphi 7 and later (and for JPEG imag
> I'm not too happy with c-obj files. I would prefer one of the many
> Delphi ports.
Why? Using a Pascal port of a C code is a maintenance nightmare, bugs
may have been introduced during the port, and it's unlikely to be kept
up to date with the latest ZLIB version, so may have security
vulne
>> I wonder if we shouldn't simply push the compression code into that
>> beta. This is probably the only way to have people really testing it
>> (well beside pushing it into the release).
> I suspect many developers, including myself, use the 'beta' as their
> working version of ICS in live appli
> I wonder if we shouldn't simply push the compression code into that
> beta. This is probably the only way to have people really testing it
> (well beside pushing it into the release).
I suspect many developers, including myself, use the 'beta' as their
working version of ICS in live applicati
>>> Am I right in thinking the HTTP compression stuff has not
>>> yet made it into a released ICS?
>>Indeed. It was out of my head.
>>I should re-read the last messages published with that subject...
> If you need any help to refresh your memory I'm there :-)
I plan to release the current beta w
On 19-Nov-05 19:48:43 Francois PIETTE wrote:
>> Am I right in thinking the HTTP compression stuff has not
>> yet made it into a released ICS?
>Indeed. It was out of my head.
>I should re-read the last messages published with that subject...
If you need any help to refresh your memory I'm there :
> Am I right in thinking the HTTP compression stuff has not
> yet made it into a released ICS?
Indeed. It was out of my head.
I should re-read the last messages published with that subject...
--
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
http:/
40 matches
Mail list logo
