[twsocket] HTTP client component and document encoding

2005-07-21 Thread Francois PIETTE 
Maurizio Lotauro is working on the HTTP client component to extend the work 
already done by Xavier Le Bris (gzip support). The idea is to have a general 
mechanism in the component to register encoding system so that adding new 
encoding scheme doesn't require component change.

Preliminary code is available from 
http://www.overbyte.be/arch/dump/HttpContCod.zip
Any comment is welcome !

Message from Maurizio:
-- cut here --
this is the result of my work to handle the content encoding in the THttpCli
component.
The HttpContCod.pas contains all classes needed for this purpose.

The THttpContentCoding class is used as base to handle a specific coding.
It should implement:
- Create costructor Parameters are
  - ACoding: is the name of the coding (for example 'gzip')
  - AStream: is the stream where the result of decoding will be put
  There must create the InputStream. It will receive the data to decode.
- Destroy
Must free the InputStream created in the Create costructor
- Complete
This method will called when there are no more data to decode

In the Initialization section a THttpContCodHandler.RegisterContentCoding 
must
be called.
Note that a single class can potentillly handle more encodings. In this case
more register must be called.
Parameters are:
- Coding: the name of the coding (for example 'gzip')
- DefaultQuality: this is the quality set as default. It could be changed by
code
- ContCodClass: the class inherited from THttpContentCoding.

The HttpCCodGzip is a sample that should reproduce what Xavier has proposed.
Notice that in the original the FLastResponse and FContentLength are 
changed.
I haven't reported this, tell me if it is necessary or not.

About streaming or not, it depend how the THttpContentCoding is implemented.
Is the sample the decoding is done a the end, but it could be done on the 
fly
if the InputStream is able to do it.

In the HttpProt all changes are between a {$IFDEF UseContentCoding}. I
introduce three new variables:
- FContentEncoding: will contain the Content-Coding header value
- FContentCodingHnd: it is used to prepare the Accept-Encoding and handle
the Content-Coding
- FRcvdStreamStartSize: used to cleanup the RcvdStream insted using
FRcvdCount, that sitll contain the count of what effectly has received.

I prepare the FContentCodingHnd after the TriggerDocBegin. I hope that is 
the
last point were the RcvdStream could be set, otherwise it will not work.

Note that two Coding are implicit defined: identity and *. See RFC 2068
for details.

This is a first step, only to check if the logic is correct. Probably other
properties are needed to enable/disable these new functionality.
I'm not able to test if the gzip is working or not. The URL contained in the
HttpProtZ.zip doesn't work for me.
-- cut here --

I commented the code, made some suggestion and here is the result of our 
messages:

-- cut here --

  Another reason could be that a class could handle similar encoding,
  but probably it is better to have different classes that inherited
  from a common one.

 Yes, indeed.

Ok, I made the changes in this way.

  Why not define a class function? In that case you do not need to
  create and destroy only to get a fixed name.

 Class method can't be virtual, or can tham ?

Yes they can, and they could even be abstract.

  In any case I prefer to have a single way to get the coding name, it
  seems more clean to me.

 What I propose is a single way: GetEncodingName. Either the base
 implementation extracting the name from class name, or overrided in 
 derived
 classes to give a specific name.

Ahh ok, now I understood what you mean. Changed the code accordnly.

 btw: Xavier sent a message to stating he is back from holidays. We should
 really move this discussion to the mailing list so that anyone can
 participate. I don't know why you sent the message to me only at the first
 place.

Because the changes involved more the internal behaviour of the component 
than
the adding of gzip capability, and I would like to hear your opinion first.
And because I haven't the email of Xavier at hand when I write :-)

I attached a new zip containg the changes you suggested. Check it and
eventually make it available to other people so we can start a discussion in
the ML. I hope that more people than me and you will partecipate...

-- cut here --

--
[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 client component and document encoding

2005-07-21 Thread Maurizio Lotauro 
Scrive Francois PIETTE [EMAIL PROTECTED]:

 class function THttpContentCoding.GetCoding: String;
 const
   BASE_CLASS_NAME = 'THttpContentCoding';
 begin
   if Pos(BASE_CLASS_NAME, ClassName) = 1 then
 Result := Copy(ClassName, Length(BASE_CLASS_NAME), MAXINT)
   else
 Result := 'Unknown';  { Raise an exception?? }
 end;
 
 Instead of Result := 'Unknown'; I would code:
 
 raise Exception.Create('GetCoding must be overriden in ' + ClassName);
 
 Probably a new exception class should be created, like 
 HttpContentCodingException to ease exception handling in the application.

Done.


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