[racket] More consistent approach to web programming?

Oh really, I also won an award for Most Ironic Spelling, in
recognition of my use of "exaxtly"?

Gah.

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