Re: AHC API
On Nov 23, 2009, at 4:19 PM, Alan D. Cabrera wrote: > Ahh, well, I did state that it was only "bit" awkward but, now that I know > who wrote it I can call it a "steaming pile" ;) (Just kidding)r DOH! > > Actually I was talking about the proposed API that we had worked out a while > back. Not the 1.x from Geronimo. > Whew! /me notices no dust as he guesses he wasn't actually thrown under the bus and it was just a bad dream > Look at ClientTest.testSendMultipleAttachments() and ClientTest > .testReceiveMultipleAttachments() for a thin mockup of my ideas. A more > "concrete" use can be seen in my S3 API implementation mentioned above. > I'll have a looksy. I look forward to seeing what is here ;-) Jeff > > Regards, > Alan > >
Re: AHC API
On Nov 23, 2009, at 2:34 PM, Jeff Genender wrote: On Nov 23, 2009, at 2:47 PM, Alan D. Cabrera wrote: I've checked in my *very* rough initial thoughts for an API. I "vetted" them against an Amazon S3 API that I am working on https://svn.codehaus.org/livetribe/nursery/livetribe-s3-api . Can you point out a little more specifically? Can you point out the http specific code? https://svn.codehaus.org/livetribe/nursery/livetribe-s3-api/rest/src/main/java/org/livetribe/s3/rest/v20060301/RestS3API.java There was a discussion on this a while back. I thought that the connector/connection/client/factory was a bit awkward, imho. There were a few other things but rather than making a tedious comparison I thought that I would just highlight what I think are the key important features of the my API sketch. Hehe - the connector/connection/client/factory was my awkward implementation. ;-) Ahh, well, I did state that it was only "bit" awkward but, now that I know who wrote it I can call it a "steaming pile" ;) (Just kidding) Actually I was talking about the proposed API that we had worked out a while back. Not the 1.x from Geronimo. If I understand the code it seems that we mixed two APIs into one; it's been a while since we discussed it. Each would accomplish something from a different perspective. Both interesting on its own. Would that be a good characterization? I'm pretty sure that it can support all the use cases listed in http://cwiki.apache.org/AWEB/client-use-cases.html plus a few more. My API is pretty simple. Factories create clients and clients create connections; you can forgo the use of factories. Connections can be reused to implement load balancing/proxying. You'll notice that the core components are not littered with implementation parameters. These are left to implementations of HttpConfig. Yeah that makes a lot more sense. I have an asynchronous mechanism to download content as the HTPP response is being parsed. I think my mechanism for supplying multiple MIME content is pretty clean. Can we see it? Look at ClientTest.testSendMultipleAttachments() and ClientTest .testReceiveMultipleAttachments() for a thin mockup of my ideas. A more "concrete" use can be seen in my S3 API implementation mentioned above. Regards, Alan
Re: AHC API
On Nov 23, 2009, at 2:47 PM, Alan D. Cabrera wrote: I've checked in my *very* rough initial thoughts for an API. I "vetted" them against an Amazon S3 API that I am working on https://svn.codehaus.org/livetribe/nursery/livetribe-s3-api . Can you point out a little more specifically? Can you point out the http specific code? There was a discussion on this a while back. I thought that the connector/connection/client/factory was a bit awkward, imho. There were a few other things but rather than making a tedious comparison I thought that I would just highlight what I think are the key important features of the my API sketch. Hehe - the connector/connection/client/factory was my awkward implementation. ;-) /me dusts himself off after the bus is done running him over ;-) At the time my employer needed something literally within one week to show to its client. So I simply mirrored some of the Mina API to keep it simple, while at the same time utilizing GOF best practice patterns. This was before me running it by anyone. So lets just say it was something I literally threw together (but as a positive note, it certainly performed darn well) ;-) I'm pretty sure that it can support all the use cases listed in http://cwiki.apache.org/AWEB/client-use-cases.html plus a few more. My API is pretty simple. Factories create clients and clients create connections; you can forgo the use of factories. Connections can be reused to implement load balancing/proxying. You'll notice that the core components are not littered with implementation parameters. These are left to implementations of HttpConfig. Yeah that makes a lot more sense. I have an asynchronous mechanism to download content as the HTPP response is being parsed. I think my mechanism for supplying multiple MIME content is pretty clean. Can we see it? Jeff Extensions of HttpListener can be added to obtain various events. I thought that the type safety of listeners would be preferred to a generic HttpEvent listener. There may be overlap with existing APIs. Regards, Alan
AHC API
I've checked in my *very* rough initial thoughts for an API. I "vetted" them against an Amazon S3 API that I am working on https://svn.codehaus.org/livetribe/nursery/livetribe-s3-api . There was a discussion on this a while back. I thought that the connector/connection/client/factory was a bit awkward, imho. There were a few other things but rather than making a tedious comparison I thought that I would just highlight what I think are the key important features of the my API sketch. I'm pretty sure that it can support all the use cases listed in http://cwiki.apache.org/AWEB/client-use-cases.html plus a few more. My API is pretty simple. Factories create clients and clients create connections; you can forgo the use of factories. Connections can be reused to implement load balancing/proxying. You'll notice that the core components are not littered with implementation parameters. These are left to implementations of HttpConfig. I have an asynchronous mechanism to download content as the HTPP response is being parsed. I think my mechanism for supplying multiple MIME content is pretty clean. Extensions of HttpListener can be added to obtain various events. I thought that the type safety of listeners would be preferred to a generic HttpEvent listener. There may be overlap with existing APIs. Regards, Alan
Re: AHC api
Alan D. Cabrera wrote: No Karma. :( Let's vote ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: AHC api
On Nov 17, 2009, at 8:37 PM, Ashish wrote: On Wed, Nov 18, 2009 at 9:59 AM, Jeff Genender > wrote: Why not sandbox (i.e. make a place in the sandbox) the idea and send a pointer to the list? I look forward to seeing what you have! Jeff On Nov 17, 2009, at 9:00 PM, Alan D. Cabrera wrote: Heh, heh. I should have been more explicit. I have a set of interfaces and would like to check them in for people to throw darts at. sandbox is the right place, but don't think Alan can put code in there? I would recommend creating a JIRA and attach the code to it, and one of the committers can add the code to sandbox like we did for protocolbuffs codecs. Works for me. Regards, Alan
Re: AHC api
On Wed, Nov 18, 2009 at 9:59 AM, Jeff Genender wrote: > Why not sandbox (i.e. make a place in the sandbox) the idea and send a > pointer to the list? > > I look forward to seeing what you have! > > Jeff > > > On Nov 17, 2009, at 9:00 PM, Alan D. Cabrera wrote: > >> Heh, heh. I should have been more explicit. I have a set of interfaces and >> would like to check them in for people to throw darts at. sandbox is the right place, but don't think Alan can put code in there? I would recommend creating a JIRA and attach the code to it, and one of the committers can add the code to sandbox like we did for protocolbuffs codecs. thanks ashish
Re: AHC api
No Karma. :( Regards, Alan On Nov 17, 2009, at 8:29 PM, Jeff Genender wrote: Why not sandbox (i.e. make a place in the sandbox) the idea and send a pointer to the list? I look forward to seeing what you have! Jeff On Nov 17, 2009, at 9:00 PM, Alan D. Cabrera wrote: Heh, heh. I should have been more explicit. I have a set of interfaces and would like to check them in for people to throw darts at. Regards, Alan On Nov 17, 2009, at 7:57 PM, Jeff Genender wrote: Looks like you have the right list? ;-) Jeff On Nov 17, 2009, at 7:23 PM, Alan D. Cabrera wrote: I want to flesh out a new async http client. I've got my own ideas for the api and would like to check them in to solicit comments. Where would be a good place to put this? Regards, Alan
Re: AHC api
Why not sandbox (i.e. make a place in the sandbox) the idea and send a pointer to the list? I look forward to seeing what you have! Jeff On Nov 17, 2009, at 9:00 PM, Alan D. Cabrera wrote: > Heh, heh. I should have been more explicit. I have a set of interfaces and > would like to check them in for people to throw darts at. > > > Regards, > Alan > > On Nov 17, 2009, at 7:57 PM, Jeff Genender wrote: > >> Looks like you have the right list? ;-) >> >> Jeff >> >> >> >> On Nov 17, 2009, at 7:23 PM, Alan D. Cabrera wrote: >> >>> I want to flesh out a new async http client. I've got my own ideas for the >>> api and would like to check them in to solicit comments. Where would be a >>> good place to put this? >>> >>> >>> Regards, >>> Alan >>> >> >
Re: AHC api
Heh, heh. I should have been more explicit. I have a set of interfaces and would like to check them in for people to throw darts at. Regards, Alan On Nov 17, 2009, at 7:57 PM, Jeff Genender wrote: Looks like you have the right list? ;-) Jeff On Nov 17, 2009, at 7:23 PM, Alan D. Cabrera wrote: I want to flesh out a new async http client. I've got my own ideas for the api and would like to check them in to solicit comments. Where would be a good place to put this? Regards, Alan
Re: AHC api
Looks like you have the right list? ;-) Jeff On Nov 17, 2009, at 7:23 PM, Alan D. Cabrera wrote: > I want to flesh out a new async http client. I've got my own ideas for the > api and would like to check them in to solicit comments. Where would be a > good place to put this? > > > Regards, > Alan >
AHC api
I want to flesh out a new async http client. I've got my own ideas for the api and would like to check them in to solicit comments. Where would be a good place to put this? Regards, Alan