On Thu, Oct 7, 2010 at 3:26 PM, Greg Hendershott <greghendersh...@gmail.com> wrote: > 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.
It should not be hard to remain compatible with the parts of the Web server that use the request/response structs or to abstract them so they can handle both yours and the defaults. Jay > > 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 > -- Jay McCarthy <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
