On 17-Aug-05 10:32:00 Angus Robertson - Magenta Systems Ltd wrote:

>> How do you think that all we heavily tested for weeks if nobody,
>> except the developer(s), made any test?

>I only have a single development environment, and I need to be able to
>produce bug fix versions of several applications at short notice, often
>hours, that get widely distributed within hours.

>Many other professional developers are probably in exactly the same

I'm one. Actually I'm using only the HttpCli component. To do a test
I normally use a modified version of HttpTst. To not affect the
compilation of other application I copy the new files (HttpProt in
this case) to the dir of the test application. With this way only
this program will use the "new" version, so the other projects are

>So using new versions of components is very delicate, thus the absolute
>need for backward compatibly and full version and change documentation,
>to allow the risk of new versions to be accessed.

The changes that I made are backward compatible. If they aren't then
there is a bug.

>I do keep up to date with official ICS betas, including SSL, test them
>for weeks or months in various live applications, report problems, and
>often try to fix them myself, for the benefit of other uses, but only
>if I can see the risk of doing so and I can be sure the changes will
>not cause me major grief.

This exactly what I normally do, and what every good programmer
should do :-)

BTW, there is another "test" version of HttpCli. If you missed it,
this solve a potential problem that could raise when both the proxy
and the host require an authentication. The symptom is very bad: the
application goes in a infinite loop!

So it is very important that people test it because it change the
logic of how the autentication is handled internally.
I worked two weeks to solve it. It take so long because I repeated
the test with an huge amount of combination every time I changed the
See old post for details.

>> We are not speaking specific on gzip but on handlig encoding in a
>> generic way.

>Not really fussed how many different fancy schemes are supported.

This was not only a problem of different encoding, but of different
implementation. What I want to avoid is that an application need two
different zip libraries because the component "need" a different one
to handle the gzip encoding.
And this will help a lot in the compability field, in particular when
it is planned to use a different zip library in the future.

>> If you are using VCLZip library to handle gzip content then it could
>> be interesting to see if you are able to add it to this "new" version
>> or if it is missing something indispensable.

>Vclzip is commercial, I used it to replace the previous Borland Zlib
>implementation because it was convenient, but I'd rather use open
>source for anything new.

>I will test your changed component in one of my applications provided,
>provided there is no DLL requirement.

There is no need of dll. To test it you need HttpProt.pas and
HttpContCod.pas contained in HttpContCod.zip that is on ICS site.
To use the new code you must define Use_ContentCoding, otherwise the
code is exactly the same of the last release (and of course in that
case there is no need of the HttpContCod unit).
Using only these units no encodings will handled by the component, so
all should be backward compatible.
To enable an encoding you must include in the uses clause of one unit
of your project a unit that contain a class able to handle, for
example, the gzip. The HttpCCodGzip.pas is a sample. To work it need
all other files contained in the zip, dll included.

I invite you to test it first without gzip and then with gzip using
the VCLZip library. To implement it write a new unit following
HttpCCodGzip.pas as sample. It should be very easy (that unit is only
59 lines long). If you have questions I'm there.

Of course feedback are welcome :-)

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

Reply via email to