[racket] More consistent approach to web programming?

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.chen at gmail.com> wrote:
> On Wed, Oct 6, 2010 at 7:44 PM, Greg
> Hendershott <greghendershott at 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
>