On Wed, Mar 21, 2012 at 5:50 PM, John Clements <cleme...@brinckerhoff.org>wrote:
> Wait… don't Racket's built-in libraries already handle all of those cases? > > This is not a rhetorical question: I'm perfectly happy to be wrong, here, > but it looks like I can use get-pure-port or post-pure-port to handle > these. I guess I assumed that the original poster wanted something that > Racket didn't already include, but I could be wrong: > I'm unaware of any specific capability my http client has over standard one included in the Racket library. In fact I use the out of the box Racket SSL support. If there are differences, I'm sure the gaps will be in my library. From a non-functional perspective my HTTPClient is 100% Typed/Racket but that is of little matter. To be honest I think I did run into a small, but specific HTTP/1.1 gap in the Racket standard library long back, but I can't recall it and odds are it's there now. So how did it happen .... Originally the library was written on Larceny using R6RS modules and R6RS standard libraries and had some low level hooks into Larceny threading. For example, I added epoll() and non-blocking to Larceny + HTTPClient years ago. At one point I decided to migrate the project from Larceny to Racket[1] and after a bit of a think decided to port the HTTPClient library rather then re-write the project to the Racket standard http client. One need included the ability to have a super tiny minimal HTTP server capability for things like OAuth call backs in a Racket App, so I ended up porting the whole thing. [1]Please note there was no particular failing with Larceny other then 64-bit support. I still think Larceny is a fantastic Scheme implementation which is very much under appreciated within the general user community.
____________________ Racket Users list: http://lists.racket-lang.org/users
