Re: [twsocket] HTTP compression
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 in separate files. What happen is that the SSL update can be out more often than the standard because it is a work in progress. So no branch is needed. 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
Re: [twsocket] HTTP compression
- Original Message - From: Angus Robertson - Magenta Systems Ltd [EMAIL PROTECTED] To: twsocket@elists.org 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. 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 NTLM changes that you must have done, but which were missing from your 28th August version. But at least everything is now consolidated. 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. Dan -- 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
Re: [twsocket] HTTP compression
I've merged your HttpProt changes into the latest version, and added the LocationChangeMaxCount feature to prevent endless relocation looping. The component is backward compatible, when option httpoEnableContentCoding is not used, but does now need your HttpContCod.pas unit to be added to the ICS distribution. Using your HttpCCodGzip unit, while enabling compression adds the correct header to the protocol, suggesting it's all linked OK, unfortunately the HEAD request just gets a status of 0. = Connected to: web4 HEAD /dunman/default.asp HTTP/1.0 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Accept-Encoding: gzip User-Agent: Mozilla/4.0 (compatible; ICS) Host: web4 Can Not Access URL: http://web4/dunman/default.asp, (0) I suspect that the encoding header should not be sent with the HEAD request, I'll try and change the code tomorrow. Angus Original Message *Subject:* Re: [twsocket] HTTP compression *From:* Maurizio Lotauro [EMAIL PROTECTED] *To:* ICS support mailing twsocket@elists.org *Date:* Tue, 22 Nov 2005 17:11:01 +0100 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 the ICS web page (it is the first in the list of beta). Probably it is not in sync with latest beta but for evaluation it should not matter. To test it you can use the standard HttpTst demo. Uncompress the zip in the same dir and add HttpCCodGzip to the uses of one unit of the project. So you can test it without messing your ICS installation. If you don't add HttpCCodGzip then the gzip encoding will not be used and the component should work as usual. The header of HttpContCod.pas contains a brief description. 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
Re: [twsocket] HTTP compression
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 compatible, when option httpoEnableContentCoding is not used, but does now need your HttpContCod.pas unit to be added to the ICS distribution. This is intentional. I write all the logic into a separate unit instead directly into HttpProt unit. More easier to maintain. So yes, the HttpContCod is intended to be part of ICS package. Using your HttpCCodGzip unit, while enabling compression adds the correct header to the protocol, suggesting it's all linked OK, unfortunately the HEAD request just gets a status of 0. [...] I suspect that the encoding header should not be sent with the HEAD request, I'll try and change the code tomorrow. Maybe yes, but status 0 is a strange result. Tell us the results of your change. Eventually I'll look into it next weekend. 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
Re: [twsocket] HTTP compression
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. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- 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
Re: [twsocket] HTTP compression
- Original Message - From: Maurizio Lotauro [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Tuesday, November 22, 2005 6:15 PM Subject: Re: [twsocket] HTTP compression 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? ZLib basically supports two formats: Deflate/.z and GZip/.gz. The second one is the first one plus headers/trailers and in order to form the headers, it needs the entire file to be compressed prior to first packet is sent. We use .gz for HTTP because it is better compatible with browsers but for FTP, deflate is the standard. Best Regards, SubZ Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- 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 -- 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
Re: [twsocket] HTTP compression
- Original Message - From: Francois Piette [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org 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 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 to signal data is compressed and how it is. FYI, in FTP servers, Mode Z is used for ZLib'ed (deflate) transfers. The client sends the Mode Z command and the server decides to apply the compression for download object either by the coefficient it decided on its own or by the again client's OPTS command. You will need to modify SendNextData for downloads. I can send you code snippets if you would like to have. Just check out http://www.fastream.com/netfileserver.htm and let me know if this is what you have on your mind. Best Regards, SZ -- [EMAIL PROTECTED] http://www.overbyte.be -- 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 -- 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
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 (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 application. I disagree. Given that ICS is essentially undocumented, if people have to go searching through dozens of demo applications to find the compression code, they simply won't do it. ICS is supposed to be high level components that include such functionality. Since Zlib is part of the VCL in Delphi 7 and later, and 2006 has the latest version, it makes sense to simply use the VCL, in exactly the same way as we use the VCL for numerous other things. Assuming it's implements the features we need. If some developers are not satisfied with the VCL ZLIB, they can override the components and include whatever code they want. I'm not sure of the ZLIB state in Delphi 6 and earlier, I think it needed to be installed separately, but since I seem to be only one here that using anything older than Delphi 7 (which I'm now migrating away from), it probably does not matter. Angus -- 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
Re: [twsocket] HTTP compression
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 like this. I agree, if something is broken and all steps to make it backward compatible fail, applications need to be changed. But the August 2005 changes to the MimeDec source are undocumented in the file, the last change date was July 2004. There was a message in this list 27 Aug listing 10 changes, but it makes no comments about changes needed to make application work with the new component and no new demo was provided. I seem to recall we were told to read RCFs to find out how MIME works and to study the source line by line to find out how to use it. So we don't use it. Angus -- 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
Re: [twsocket] HTTP compression
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 include it (or another implementation) in the application. I disagree. Given that ICS is essentially undocumented, if people have to go searching through dozens of demo applications to find the compression code, they simply won't do it. ICS is supposed to be high level components that include such functionality. Since Zlib is part of the VCL in Delphi 7 and later, and 2006 has the latest version, it makes sense to simply use the VCL, in exactly the same way as we use the VCL for numerous other things. Assuming it's implements the features we need. 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. If some developers are not satisfied with the VCL ZLIB, they can override the components and include whatever code they want. I'm not sure of the ZLIB state in Delphi 6 and earlier, I think it needed to be installed separately, but since I seem to be only one here that using anything older than Delphi 7 (which I'm now migrating away from), it probably does not matter. 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 - for example). The advantage of having it in a demo, and even using an external DLL in that demo, would be to explain how one can : - create a compression/descompression component - idem as above but as a wrapper for an external compression method stored in a DLL IMHO, after having read all the thread :) Best regards, -- Guillaume MAISON - [EMAIL PROTECTED] 83, Cours Victor Hugo 47000 AGEN Tél : 05 53 87 91 48 - Fax : 05 53 68 73 50 e-mail : [EMAIL PROTECTED] - Web : http://nauteus.com -- 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
Re: [twsocket] HTTP compression
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 just another stream format. It was never necessary to put compression into the HttpProt component in the first place. I wrote an application that handles compressed pages using ZLIB several years ago - the stream is uncompressed in the RequestDone event using half a dozen lines of code (that I've posted to this mailing list in the past). 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, provide the new component is fully backward compatible and does not break my application. Angus -- 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
Re: [twsocket] HTTP compression
So essentially what you ask is that the default implementation use C-Obj ZLib delivered with Delphi. -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be - Original Message - From: Angus Robertson - Magenta Systems Ltd [EMAIL PROTECTED] To: twsocket@elists.org 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 (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 application. I disagree. Given that ICS is essentially undocumented, if people have to go searching through dozens of demo applications to find the compression code, they simply won't do it. ICS is supposed to be high level components that include such functionality. Since Zlib is part of the VCL in Delphi 7 and later, and 2006 has the latest version, it makes sense to simply use the VCL, in exactly the same way as we use the VCL for numerous other things. Assuming it's implements the features we need. If some developers are not satisfied with the VCL ZLIB, they can override the components and include whatever code they want. I'm not sure of the ZLIB state in Delphi 6 and earlier, I think it needed to be installed separately, but since I seem to be only one here that using anything older than Delphi 7 (which I'm now migrating away from), it probably does not matter. Angus -- 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 -- 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
Re: [twsocket] HTTP compression
Scrive Fastream Technologies [EMAIL PROTECTED]: - Original Message - From: Francois Piette [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org 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 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 to signal data is compressed and how it is. FYI, in FTP servers, Mode Z is used for ZLib'ed (deflate) transfers. The client sends the Mode Z command and the server decides to apply the compression for download object either by the coefficient it decided on its own or by the again client's OPTS command. You will need to modify SendNextData for downloads. One question could be: should the client automatically decormpress the downloaded file or it should be done by the application? I can send you code snippets if you would like to have. Just check out http://www.fastream.com/netfileserver.htm and let me know if this is what you have on your mind. As said I'm not using the ftp component. Someone that has worked on this can jump in this thread? Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- 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
Re: [twsocket] HTTP compression
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 - for example). The advantage of having it in a demo, and even using an external DLL in that demo, would be to explain how one can : - create a compression/descompression component - idem as above but as a wrapper for an external compression method stored in a DLL IMHO, after having read all the thread :) It seems to me that you have exactly got my point :-) Bye, Maurizio. This mail has been sent using Alpikom webmail system http://www.alpikom.it -- 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
Re: [twsocket] HTTP compression
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 uncompressed file, this is all explained at: http://ietfreport.isoc.org/all-ids/draft-preston-ftpext-deflate-03.txt The fun part seems to be resumed transfers, part way through a compressed file, not quite sure how that's implemented, particularly when decompressing a partially downloaded file. Also whether the file is totally compressed before transfer. I was downloading some 250 meg text files last week, that would have been a lot less painful with compression. Angus -- 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
Re: [twsocket] HTTP compression
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, provide the new component is fully backward compatible and does not break my application. 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? 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
Re: [twsocket] HTTP compression
Restarting is done in terms of offsets of uncompressed file. For example: Let's assume deflate compresses file A by 50%. The file is 100Bytes. And the packet size is 1 bytes. After 25 packets which is 50 bytes, transfer is aborted by client. Then when he returns back, he sends the command: REST 50 NOT REST 25. The server then starts compression (deflate works by packet-by-packet way) of the rest 50 bytes and there is 25 bytes more to go for compressed transfer. The bad thing is that you cannot cache compressed content because of this REST problem. So everything is on-the-fly! I would give you my code but it's in C++. Thanks, SZ - Original Message - From: Angus Robertson - Magenta Systems Ltd [EMAIL PROTECTED] To: twsocket@elists.org Sent: Monday, November 21, 2005 5:55 PM Subject: Re: [twsocket] HTTP compression 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 uncompressed file, this is all explained at: http://ietfreport.isoc.org/all-ids/draft-preston-ftpext-deflate-03.txt The fun part seems to be resumed transfers, part way through a compressed file, not quite sure how that's implemented, particularly when decompressing a partially downloaded file. Also whether the file is totally compressed before transfer. I was downloading some 250 meg text files last week, that would have been a lot less painful with compression. Angus -- 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 -- 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
Re: [twsocket] HTTP compression
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 within a few days/weeks, immediately after Delphi 2006 is available in shops. And then start a new beta beta version. As with previous Delphi releases, ICS MidWare should be delivered by Borland into Delphi 2006 retail box, actually on the companion CD. 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 ? -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- 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
Re: [twsocket] HTTP compression
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 applications, and expect major changes to have been properly tested for backward compatibility before being 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, and HttpProt is hard to test because the developer is expected to supply their own ZLIB compression code (use of a DLL is unacceptable for a component). 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. Angus -- 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
Re: [twsocket] HTTP compression
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 applications Beta version is always to one I use myself in my applications. 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'm not too happy with c-obj files. I would prefer one of the many Delphi ports. 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 compressions quickly available (read DLL) and then replace that code with something else. This way we can debug HTTP part of the code separately from actual compression code. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- 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
Re: [twsocket] HTTP compression
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 vulnerabilities. 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 might need a more recent ZLIB. I've now managed to build most of my applications in Delphi 7, as a stepping stone to Delphi 2006, so am rapidly losing interest in Delphi 6 and earlier. Angus -- 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
Re: [twsocket] HTTP compression
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 images), so if it's good enough for them, it should be good enough for us. Borland is not the champion of keeping things on the long term. The already deprecated many code or component they included. All they are interrested in is selling their next environment. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- 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
Re: [twsocket] HTTP compression
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, and 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. But since all of you are more interested in leaving your software working improperly, I've dropped further TMimeDec development. My last patches are in the TMimeDec beta available (AFAIR) on Overbyte website - if anyone wants them, feel free to use them. Thanks. -- Piotr Hellrayzer Dalek [EMAIL PROTECTED] -- INTERIA.PL | Kliknij po wiecej http://link.interia.pl/f18c1 -- 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
Re: [twsocket] HTTP 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 don't know the FTP component, maybe what I proposed can be modified to share some code for support both protocols? 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
Re: [twsocket] HTTP compression
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 compressions quickly available (read DLL) and then replace that code with something else. This way we can debug HTTP part of the code separately from actual compression code. 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 application. 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
Re: [twsocket] HTTP compression
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 you to put the code in the beta. 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
Re: [twsocket] HTTP compression
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 might need a more recent ZLIB. In Delphi 5 the source of Jpeg and Zlib are in the companion CD (and the Zlib has a bug, at least in that version). 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
Re: [twsocket] HTTP compression
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 to signal data is compressed and how it is. -- [EMAIL PROTECTED] http://www.overbyte.be -- 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
[twsocket] HTTP compression
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://www.overbyte.be -- 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
Re: [twsocket] HTTP compression
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 :-) 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
