[racket] More consistent approach to web programming?

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:

   1. bytes - since many files are binary instead of text, you will want to
   allow for bytes
   2. ports - if you allow for bytes, then allowing for ports will also make
   sense, especially for large files
   3. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20101007/583c9dcf/attachment.html>