[racket] More consistent approach to web programming?

More great points.

I agree it's harder to parse than to request.

I think there's a cluster of details (like Transfer-Encoding,
Chunked-Encoding, nailing the byte count exaxtly for persistent
connections, etc.) that are equal-opportunity annoyances for client
and server. It would be great to embrace equal-opportunity solutions
in the provided libs. Sometimes they really are two sides of the same
coin, and it can be short strokes for someone to address both while
they have the hood open anyway. (Yeah I know: I will now accept my
prize for mixing three metaphors in one sentence. I'd like to thank my
mother, my manager ... )

On Thu, Oct 7, 2010 at 5:38 PM, YC <yinso.chen at gmail.com> wrote:
>
> On Thu, Oct 7, 2010 at 2:26 PM, Greg Hendershott <greghendershott at gmail.com>
> wrote:
>>
>> 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.
>
> The different level of difficulty comes from that you are generating a
> request on the client, but trying to parse a request on the server.  If you
> focus on just generating a response on the server (or also try to parse the
> response on the client), then the two will be roughly on par.
> Basically it is harder to parse than to generate.  So I would say having a
> translation layer will be the way to go for now, until in the future you are
> ready to parse the request yourself, that's when the ol' good RFCs come in
> handy.
> Cheers,
> yc
>
>
>