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? Oleg 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
