hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HLCA: http entities - take two
Date Sat, 22 Jan 2005 11:39:40 GMT
Hi Roland

I am +1 on committing these changes to the AP redesign document. 

I have only one comment. Let us not get too obsessed with details at
this moment. The exact method signatures and design patterns may be
difficult to get right at this level of abstraction. Probably we should
even try. 

The main goal of this work, imo, is to determine the most fundamental
interfaces and classes, relationship between these classes, and the most
efficient packaging of related classes and interfaces with least amount
of coupling and external dependencies. The rest the code will tell.

In this vein I suggest we leave method signatures out of this document

-  HttpMessage as base interface for HttpRequest, HttpResponse
-    - getHeader(), setHeader()

+ HttpMessage as base interface for HttpRequest, HttpResponse. This 
+ interface defines methods to manipulate http headers.

First off, this leaves us some room for maneuvers. We will not have to
worry about invalidating the API redesign document, should we discover a
better approach. Secondly, we do not have to commit ourselves to any of
the JRE specifics. 

What do you think?


On Sat, 2005-01-22 at 08:32 +0100, Roland Weber wrote:
> Hello again,
> here is take two on moving http entities into their own
> class hierarchy. The Decorator pattern for input/output
> does not really fit, because writing or reading an entity
> is not a functionality that can be implemented without
> internal knowledge of the entity itself.
> What I intend is closer to the Strategy pattern. There
> is a strategy for writing an entity, and one for reading
> an entity. The various Ic and Og classes implement such
> strategies for a particular type of entity.
> To reduce the number of classes, I have moved both strategies
> into one for the simple in-memory entity types. I also dropped
> the BasicOgEntity and BasicIcEntity classes because I don't
> know what would actually be implemented there and because
> I can't derive from both of them at the same time.
> Here is what it looks like now, with suggestions for the
> methods that go into some of the classes and interfaces.
> I'm old-fashioned, so it's java.io rather than java.nio
> for the time being ;-)
> http-common
>   HttpMessage as base interface for HttpRequest, HttpResponse
>     - getHeader(), setHeader()
>   HttpEntity interface
>     - getContentLength(), getContentType()
>   HttpOutgoingEntity interface extends HttpEntity
>     - isRepeatable(), writeTo(OutputStream)
>   HttpIncomingEntity interface extends HttpEntity
>     - readFrom(HttpMessage, InputStream) ?
>       (or have that functionality in a constructor)
>   BasicEntity implements HttpEntity
>     - public getContentLength(), getContentType()
>     - protected setContentLength(), setContentType()
>   StringEntity extends BasicEntity
>     implements HttpOutgoingEntity, HttpIncomingEntity
>   ByteArrayEntity extends BasicEntity
>     implements HttpOutgoingEntity, HttpIncomingEntity
>   InputStreamOgEntity extends BasicEntity
>     implements HttpOutgoingEntity
>   OutputStreamIcEntity extends BasicEntity
>     implements HttpIncomingEntity
> http-client
>   FormDataEntity extends BasicEntity
>     implements HttpOutgoingEntity, HttpIncomingEntity
>       uses commons-codec, therefore in http-client
>   MultipartOgEntity extends BasicEntity
>     implements HttpOutgoingEntity
>       based on commons-codec or code in o.a.c.hc.methods.multipart
>   MultipartIcEntity extends BasicEntity
>     implements HttpIncomingEntity
>       based on commons-codec (only if available)
>       alternative implementations based on javax.mail or
>       commons-fileupload can be kept in a "contrib" component
>       once they are contributed
> What do you think?
> cheers,
>   Roland

To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org

View raw message