Re: [AsyncWeb] Ideas for client

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Feb 29, 2008, at 2:55 PM, Mike Heath wrote:

> Alan D. Cabrera wrote:
>>
>> 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.

What is CM chaining?

>> 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.

Ok, so I guess the cause of the confusion for me would be that  
HttpConnector can generate HttpClients and HttpConnecttions.  We  
discuss this below.

>> - 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. :)

Yeah, I think that while we probably will have an HTTPConnection under  
the hood of an HTTPClient, there's no reason to stress that  
implementation detail by having a connector generate both.  I think we  
should ask how does that strengthen the metaphor? I think it  
detracts.  When we split the two we get two nice clean and easy  
metaphors for users to swallow.

We would only merge the two if it were commonplace for one to use both  
to accomplish a single task; a situation that I am stretched to  
contrive.

>> - 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.

There's great merit in sticking w/ MINA's paradigm even if, IMO, this  
bit is flawed.

I am not against checking to see if a key exists.  I'm against setting  
a key w/ no value which, IMO, smacks of an ad hoc addition.  But, in  
this case my opinion is moot and, like I said, a bike shed issue.

> 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().

The default implementation should sync on this.  Exotic  
implementations would use the IoSessionDataStructureFactory and can  
make the appropriate wrapper.  I think that it smacks of an ad hoc  
addition; JMHO.  I think that there is great value in following the  
paradigms that maps in Java use, i.e. wrap behavior.  But, in this  
additional case my opinion is moot and another bike shed issue.

>> 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.

Yeah, I'm writing a Xen API JCA Connector and want to use this puppy,  
among other things.


Regards,
Alan

Re: [AsyncWeb] Ideas for client

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Mar 18, 2008, at 11:13 AM, Mike Heath wrote:

> Alan Cabrera wrote:
>>
>> On Mar 1, 2008, at 10:43 PM, Alan D. Cabrera wrote:
>>
>>>
>>> On Feb 29, 2008, at 2:55 PM, Mike Heath wrote:
>>>
>>>> Alan D. Cabrera wrote:
>>>>>
>>>>> 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.
>>>
>>> What is CM chaining?
>>
>> Still curious.
>
> We discussed the idea of having a parent CM and a child CM would store
> its own cookies but if id didn't have a cookie it would look to its
> parent for the cookie.  This is what I was referring to when I said  
> "CM
> chaining".  I was indicating that it may be a good idea to add  
> explicit
> support to the client API for this type of parent/child relationship.
>
> I'm going to move the API we've been discussing to my sandbox so
> everyone can peruse the code and we can better discuss these ideas and
> start implementing them.  I've made a number of changes that I'm  
> anxious
> to get feedback on.


What use case does this support?  It really strikes me as odd.

But, I guess it doesn't matter so long as the parent paradigm doesn't  
sneak into the CM interface.


Regards,
Alan

Re: [AsyncWeb] Ideas for client

[Mike Heath <mh...@apache.org>]

Alan Cabrera wrote:
> 
> On Mar 1, 2008, at 10:43 PM, Alan D. Cabrera wrote:
> 
>>
>> On Feb 29, 2008, at 2:55 PM, Mike Heath wrote:
>>
>>> Alan D. Cabrera wrote:
>>>>
>>>> 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.
>>
>> What is CM chaining?
> 
> Still curious.

We discussed the idea of having a parent CM and a child CM would store
its own cookies but if id didn't have a cookie it would look to its
parent for the cookie.  This is what I was referring to when I said "CM
chaining".  I was indicating that it may be a good idea to add explicit
support to the client API for this type of parent/child relationship.

I'm going to move the API we've been discussing to my sandbox so
everyone can peruse the code and we can better discuss these ideas and
start implementing them.  I've made a number of changes that I'm anxious
to get feedback on.

-Mike

Re: [AsyncWeb] Ideas for client

[Alan Cabrera <ad...@toolazydogs.com>]

On Mar 1, 2008, at 10:43 PM, Alan D. Cabrera wrote:

>
> On Feb 29, 2008, at 2:55 PM, Mike Heath wrote:
>
>> Alan D. Cabrera wrote:
>>>
>>> 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.
>
> What is CM chaining?

Still curious.


Regards,
Alan

Re: [AsyncWeb] Ideas for client

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Mar 3, 2008, at 12:22 PM, Sangjin Lee wrote:

> I haven't had a chance to add my use case: the "scatter-and-gather"
> situation where one uses a completion queue to handle the result.   
> Hopefully
> I'll do that some time this week...
> I also would like to discuss how to get back to the request while  
> processing
> the response.  It is often desirable and sometimes even necessary to  
> find
> out the request from the response.  How should we address this?
>
> One could obviously have a direct reference to the Request from the
> Response, but there are drawbacks.  It basically means that the  
> requests
> will stick around until the response goes out of scope.  This may  
> have some
> negative consequences especially if requests are large objects and/or
> mutable.
>
> Another approach might be to refer only to certain parts of the  
> request from
> the response; e.g. the request URL.  However, it's not clear if it's  
> only
> the request URL callers would be interested in, and then the list of  
> these
> attributes may grow pretty quickly.
>
> What do others think?

I like the idea of being able to attach a user object, or handle if  
you will, to the request.  This handle will be passed back in the  
response.


Regards,
Alan

Re: [AsyncWeb] Ideas for client

[Sangjin Lee <sj...@gmail.com>]

I haven't had a chance to add my use case: the "scatter-and-gather"
situation where one uses a completion queue to handle the result.  Hopefully
I'll do that some time this week...
I also would like to discuss how to get back to the request while processing
the response.  It is often desirable and sometimes even necessary to find
out the request from the response.  How should we address this?

One could obviously have a direct reference to the Request from the
Response, but there are drawbacks.  It basically means that the requests
will stick around until the response goes out of scope.  This may have some
negative consequences especially if requests are large objects and/or
mutable.

Another approach might be to refer only to certain parts of the request from
the response; e.g. the request URL.  However, it's not clear if it's only
the request URL callers would be interested in, and then the list of these
attributes may grow pretty quickly.

What do others think?

Thanks,
Sangjin