hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ROLWE...@de.ibm.com>
Subject HLCA: http entities
Date Thu, 20 Jan 2005 12:47:37 GMT
Hello folks,

as I have briefly mentioned in a previous mail, I would like to
move the handling of HTTP entities into dedicated classes,
instead of having it in method implementations. The main
reasons for this are:

1. entities have to be put into HTTP responses as well, though
   these tend to be more simple than the multipart entities
   frequently found in requests
2. all entity enclosing methods (in particular POST and PUT)
   should provide identical means for defining entities, without
   having to duplicate code
2. on the server side, a method will provide access to the
   enclosed entity but does not allow to define it

In the light of Oleg's attempts to make request and response
objects useful on both client and server side, I believe that
separate entity handling classes will simplify re-use. And
here is my first take on it:


  HttpEntity interface
  HttpOutgoingEntity extends HttpEntity (was: RequestEntity)
  HttpIncomingEntity extends HttpEntity

  BasicEntity implements HttpEntity
  BasicOgEntity extends BasicEntity implements HttpOutgoingEntity
  BasicIcEntity extends BasicEntity implements HttpIncomingEntity

  StringOgEntity extends BasicOgEntity
  ByteArrayOgEntity extends BasicOgEntity
  InputStreamOgEntity extends BasicOgEntity

  FormDataOgEntity extends BasicOgEntity
      based on code currently in PostMethod

  OutputStreamIcEntity extends BasicIcEntity
  ByteArrayIcEntity extends BasicIcEntity

  (Rename EntityEnclosingMethod to something that can
   reasonably be implemented by HttpResponse as well?)


  MultipartOgEntity extends BasicOgEntity
      based on current code in o.a.c.hc.methods.multipart
     (Part, PartBase, StringPart, ByteArrayPart, FilePart
      PartSource, ByteArrayPartSource, FilePartSource)

  MultipartIcEntity extends BasicIcEntity
      based on Commons FileUpload - as a future extension

What do you think? I will take care of updating the
design document once we have reached a consensus.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message