a) Isn't it possible to defer call to THttpContentCoding.GetCoding until it is really needed so that exceptions are raise at that time ?
b.1) There is already a property "Options" which is a set of properties. It is better to extent this set. b.2) No opinion now. c) Acceptable. Maybe add an event with a boolean var argument "ignore". If ignore is true, nothing special happend, the document is receive undecompressed. If ignore = false then an exception is raised. Just an idea. d) I do not master the topic. Could you elaborate ? -- [EMAIL PROTECTED] http://www.overbyte.be ----- Original Message ----- From: "Maurizio Lotauro" <[EMAIL PROTECTED]> To: <twsocket@elists.org> Sent: Friday, August 12, 2005 3:37 AM Subject: [twsocket] HttpCli content encoding >I repost some points to discuss: > > a) Exception in THttpContentCoding.GetCoding method > This method is called indirectly during the initialization. It seems > that this is not the best moment to raise an exception. > When run from Delphi, if the "Stop on Delphi exception" is not > enabled, the developer see only an "Internal error 217 on ...", not > very meaningful to know what the problem is. For the same reason is > useles to have a spefic exception class. > If run outside Delphi the user see "This application has encounterd > bla bla bla do you want send a report bla bla bla". > I tried to move the check in the THttpContCodHandler.Create. In this > case when run from Delphi the developer will see what specific > exception is raised. Outside Delphi same behaviour same message "This > application ..." > I would prefer the first approach because the error is raised when > the application will run, while the second only when the form or > datamodule that contain the component will created. But the error > message will disorient the developer if he has "Stop on Delphi > exception" disabled. Opinions? > > b) New properties. > We need at least two new properties. One for disable the automatic > use of content coding and another to enable the use of Quality > specifier. I suggest to use a record type to group all properties > related to the content coding. The property could be "ContentCoding" > with "Enabled" (default false) and "UseQuality" (default false) > fields. > If it is not enabled the component will not add the "Accept-Encoding" > in the header. Should it then even ignore the "Content-Encoding"? > > c) The THttpContCodHandler.Prepare return false if there is an encode > that it is unable to decompress. Actually the HttpCli doesn't check > the result, and in this case the body will be not decompressed at > all. Is it acceptable or should this situation be handled differently? > > d) There are two coding atomatically added: "Identity" (quality=0.5) > and "*" (quality=0). Actually they are enabled by default, should > they must disabled? > Is it ok the default value of quality? > > That's all for the moment. > > > 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 -- 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
