Alan D. Cabrera wrote: > > 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 saw those. They look good. I've got a few more use cases that I would like to add as well. I hope to get around to doing that this weekend. >> 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. I like this approach. You can still share cookies across the HC's but session cookies are specific to the HC that received the session cookie. Nice. > 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. That's how I've designed my API. The HCF has a configure CM and the HC can have it's own CM if that's desired. I don't have explicit support for CookieManager chaining though. I'll have to add that. > 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. The idea that I'm trying to convey here is that the HCF (or HttpConnector in the case of my API) can hold a configuration that will be the default configuration of the HCs the HCF creates. > - 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. A lot of the configuration options are brain storming ideas. I haven't decided what I like and what I don't like yet. :) I just wanted to put ideas out there. I do agree though, I think a lot of the configuration options should be implementation specific. And as far as the user agent option goes, I was thinking that should be in the configuration in case a user wants spoof the user agent so the web server thinks the HC is IE or Firefox. > - 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? Yes, the idea is far either large read/write or for long lived connections (COMET clients). I'll try to put together or more concrete example of what I'm trying accomplish. > - I like the HttpFuture and how you can chain things. This is copied out of the MINA API. > - 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. I have to agree that I like the name HttpClientFactory too. I keep going back and forth on it though. I went with HttpConnector in my API because it's what would hold the MINA IoConnector instance and because it's creating both HttpConnections and HttpClients. The reason that I have HttpConnector creating both HttpClient and HttpConnections is because I was thinking that the HC implementation would just use an HttpConnection under the hood. This way we could create a generic HttpClient implementation that would just use a HttpConnection. We could also create a generic HttpConnection pooler that simply pool HttpConnection instances. This way we would only have to implement different HCF and HttpConnection instances to support different transports. This should make it easier for us to support different versions of MINA as well as make room for non MINA based implementations. Of course, why would anyone NOT want to use MINA? ;) As I think about it though, there's still no reason we can't separate the HttpClientFactory and the HttpConnectionFactory and still do what I just described. :) /me mulls it over > - 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. All the attribute methods were copied verbatim from MINA's IoSession. >From an implementation perspective, using an attribute w/o a value to emulate a boolean keeps things crazy simple IMO. If I need a flag I can easily see if the flag is set by calling containsAttribute. I don't have to do something like ((Boolean)connection.getAttribute(key)).booleanvalue(). We use this patter in MINA frequently. It seams to work fine and is well understood by MINA users. Synchronizing on the HttpConnection would only work of all the attribute methods were synchronized which we don't guarantee. That is why we have setAttributeIfAbsent. Besides, if you're using a ConcurrentMap to implement the attribute support, you'll want to be able to use ConcurrentMap#putIfAbsent(). > > Thoughts? Thanks for the feedback! I'm really excited to move forward with this. I've had a number of discussions with people outside of Apache WRT building an asynchronous web services client framework. The people I spoke to are specifically very interested in an asynchronous Amazon Web Services client. There's so much potential for this. -Mike
