Great points. What I had in mind was probably not as ambitious as you're thinking on in fact have already done.
On the client side, replace the various xxx-(im)pure-port functions with one: (define/contract (send-request req) (request/c . -> . response/c) ...) send-request doesn't try to do THAT much more than xxx-(im)pure-port does, except handle a few of the 80% cases like html and xml content-types. By letting request/c and response/c be not quite strictly xexprs, and allowing the element body to be a procedure? -- (output-port? -> void) or (input-port? -> void?) respectively -- you let the caller handle the 20% cases. I want to write some arbitrary bytes for the request entity, just call me to do it. I want to read some arbitrary bytes for the response entity, ditto. So now you have net/url with a (IMHO) friendlier face and a bit of help for the common cases, but still ultimately flexible. On the server side, it's tricky because I obviously wouldn't want to rewrite the Racket web server, dispatching, continuations, etc. I'm just talking about the "edge" of it that is the user-supplied dispatchee procs. Have them take a request this way and provide response this way, instead. Maybe this is where the idea gets stuck in mud, if were to come down to two bad choices: A bolt-on with too inefficient translation, or, going too far into rewriting server guts. Anyway, here's a sketch: http://github.com/greghendershott/xexpr-http I'm sure this has 101 things wrong with it, but welcome any feedback. On Thu, Oct 7, 2010 at 4:37 PM, YC <yinso.c...@gmail.com> wrote: > On Wed, Oct 6, 2010 at 7:44 PM, Greg > Hendershott <greghendersh...@gmail.com> wrote: >> >> >> Is this something where it's considered OK for everyone who wants it, >> to code it up themselves? (Have all of you in fact already done this, >> had this supposed epiphany and graduated beyond it years ago? :) ) Or >> is worth me putting something like this on GitHub or Planet? Is it >> even something to consider for Racket itself someday, considering how >> more consistency could make Racket even more appealing for web dev? > > > As Neil pointed out this will be good to be published onto planet. > I did look at a superset of this problem before (trying to parse, represent, > and generate MIME) and it was quite a complex effort with numerous of RFC to > read, etc. I ended up with just trying to get the parsing/generation right > without developing a MIME-expr to go with it yet - it's on planet as > mime.plt if that might be of interest for you to look at. > Although I didn't develop the MIME-expr yet, I did look at it from > compatibility perspective against xexpr, and the first thing that I came > across (and you might run into it) is that xexpr will not be able to > represent MIME without modifications, specifically with the following: > > bytes - since many files are binary instead of text, you will want to allow > for bytes > ports - if you allow for bytes, then allowing for ports will also make > sense, especially for large files > specific structs - header infos might be best represented as a structure > (the best example being cookies), and you might want to allow that > > While HTTP messages are not the same as MIME, they share quite a bit of > commonality and the above will apply. And depending on whether you want to > support HTTP/1.1, you might have to deal with the concept of chunked > transfers in your representation. > Hope this helps as a starting point. Cheers, > yc > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
