[racket] More consistent approach to web programming?

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

It should not be hard to remain compatible with the parts of the Web
server that use the request/response structs or to abstract them so
they can handle both yours and the defaults.

Jay

>
> 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
>>
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users
>



-- 
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://teammccarthy.org/jay

"The glory of God is Intelligence" - D&C 93