> 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
On 20-Nov-05 11:04:30 Francois PIETTE wrote:
>The question is: Should the HTTP client component implement this
>relative
>path removal algorithm ?
If it is formally valid yes. But it could be tricky to do because
sometimes the relative path could be a little "strange" :-
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 had no time to investigate the problem below (which doesn't affect my own
applications). Can someone have a look at it and propose a fix applyed to
the latest ICS beta available from my website ?
--
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
ht
>> 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
The question is: Should the HTTP client component implement this
relative
path removal algorithm ?
>>>
>>> If it is formally valid yes. But it could be tricky to do because
>>> sometimes the relative path could be a little "strange" :-)
>
>>Can you give and example of "strange" relativ
>>> 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
> I tried to figure out, wht is the best to download a couple of text files.
> I thought it was the best to do non blocking transfers (async). In my
> personal tests using public servers the async routines were faster.
> But I saw an application using blocking transfers, which got the
> data in the
16 matches
Mail list logo
