On Feb 11, 2008, at 5:27 PM, Mike Heath wrote:
I posted some use cases here:
http://cwiki.apache.org/confluence/display/AWEB/ClientUseCases They
still need some refinement to properly convey what I want but
they're a
decent start.
I've added some the use cases that I need to support.
I've also posted a hypothetical AsyncWeb Client API at
http://swamp.homelinux.net/mina/asyncweb/client/api/ with the
intent to
further promote discussion and foster more innovative ideas. I would
love to here some feedback on this API. What do you like, dislike,
not
understand? Where do you see room for improvement? The API is really
rough in places but for the most part it conveys the ideas I've had
over
the past week or so. Any suggestions for name changes to classes
and/or
methods are welcome.
Nice. This was along the same lines as I was thinking.
I like going back to my browser metaphor. I think that it fulfills
the use cases in the wiki and Rick's concerns. I realize that what
follows is a huge overlap to what you've proposed and what was
already discussed.
Let's say that we have an HttpClientFactory (HCF). This factory
would contain the default configuration that could be used to
generate any number of HttpClients (HC). I mention on the wiki that
it would be a great place to hold "permanent" cookies across HCs.
HCs can be thought of as instances of a browser. Temporary cookies
would have the same lifetime as the HCs. Configuration information
can also be set inside the HC and it would be shared across multiple
gets/puts; which addresses some of Rick's and Sangjin's concerns.
So, HCF can be optional. If you create HCs directly any cookies that
are created are scoped w/ that client. The HCF would take an
implementation of a CookieManager (CM) interface. I guess HC could
as well.
I see similarities w/ what Mike has proposed; geniuses think
alike. :) So here are the issues with what I have with that design.
Most are probably bike shed issues.
- The hierarchy is a bit confusing. HttpConnector and HttpClient
inherit off of HttpClientConfigurable but, HttpConnector can generate
HttpClients; seems odd to me in that it appears to be mixing metaphors.
- I would have left some configuration specific information out of
the HttpClientConfigurable interface and left it up to
implementations to decide what is relevant, e.g. timeouts and user
agents.
- I'm guessing that HttpConnection is used for large read/writes.
Can you put an example on the wiki on how this would be used?
- I like the HttpFuture and how you can chain things.
- I think that HttpClientFactory and HttpClient seems more concrete
than HttpConnector and HttpClient/HttpConnection. The relationship
seems a bit obtuse until one reads the javadocs and thinks on it a
bit. I suggest that we split your metaphor and have a
HttpClientFactory/HttpClient and HttpConnectionFactory/
HttpConnection. I really doubt that someone will be generating
*both* connections and clients at the same time. The factories would
extend HttpFactory which would be like HttpClientConfigurable but
without a lot of the parameters like user agent. I really like name
factory, it's an industry accepted pattern. Implementations of the
factories would have getters/setters for timeouts and what ever the
factory implementer thought was cool, e.g. pooling mumbo jumbo.
- HttpConnection, I don't see the point in setting an attribute w/out
a value just to emulate a boolean. I'm sure that I'm being dense but
I think it's important to keep it crazy simple.
- setAttributeIfAbsent can be implemented by locking on the
connection, no? I'm probably being dense here too.
Thoughts?
Regards,
Alan
