<br><div class="gmail_quote">On Thu, Oct 7, 2010 at 2:26 PM, Greg Hendershott <span dir="ltr">&lt;<a href="mailto:greghendershott@gmail.com">greghendershott@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>On the server side, it&#39;s tricky because I obviously wouldn&#39;t want to<br>
rewrite the Racket web server, dispatching, continuations, etc. I&#39;m<br>
just talking about the &quot;edge&quot; of it that is the user-supplied<br>
dispatchee procs. Have them take a request this way and provide<br>
response this way, instead. Maybe this is where the idea gets stuck in<br>
mud, if were to come down to two bad choices: A bolt-on with too<br>
inefficient translation, or, going too far into rewriting server guts.<br></blockquote><div><br></div><div>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. </div>
<div><br></div><div>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&#39;s when the ol&#39; good RFCs come in handy. </div>
<div><br></div><div>Cheers,</div><div>yc</div><div><br></div><div><br></div><div><br></div></div>