[racket-dev] Removing Xexpr preference from Web Server

From: Jay McCarthy (jay.mccarthy at gmail.com)
Date: Mon Nov 29 12:34:49 EST 2010

On Mon, Nov 29, 2010 at 3:41 AM, Nevo <sakur.deagod at gmail.com> wrote:
> Hi Jay:
>   I have a question as to what you refer as "backwards incompatible".

Most Web applications will become contract violators because they are
returning Xexprs directly to send/suspend, etc rather than returning
response data structures. I will also be cleaning up the old response
data-structures, so even those applications will have a break as well.

Jay

>   Will the old way (bytes response format) be workable since currently my
> blog server is setup by using some libs from "untyped" from planet and I'm
> not sure if this change will have any impact to those libs? Thanks,
> regardless of that, this change looks great so I don't need to worry about
> escaping and content insertion. Thank you!
> Nevo
>
> On 27 November 2010 08:55, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
>>
>> I would like to remove the implicit preference the Web Server gives to
>> Xexprs and the old esoteric bytes response format. This is backwards
>> incompatible change, but I think it will make the server better in the
>> long run as it will promote other HTML encodings, like the xml and
>> html modules, Eli's new system, SXML, etc. I am interested in your
>> opinion.
>>
>> -- Details --
>>
>> Everywhere that the server expects a "response" uses the response/c
>> contract
>>
>>
>> http://pre.racket-lang.org/docs/html/web-server/http.html#(def._((lib._web-server/http/response-structs..rkt)._response/c))
>>
>> This allows the native HTTP response data structures, Xexprs, and
>> lists that start with bytes (the MIME type) where everything after is
>> a byte string or normal string. [I have no idea where that last thing
>> came from, but it was in the legacy server and I've kept it
>> compatible.]
>>
>> In addition to backwards incompatibility, this could make Web
>> programming a bit more verbose, because you'd have to explicitly call
>> "make-xexpr-response" to construct the response from the Xexpr. I
>> could ease that a little bit by changing its name to "xexpr" or
>> something similar.
>>
>> Any ideas on the best way to deal with this?
>>
>> Jay
>>
>> --
>> Jay McCarthy <jay at cs.byu.edu>
>> Assistant Professor / Brigham Young University
>> http://faculty.cs.byu.edu/~jay
>>
>> "The glory of God is Intelligence" - D&C 93
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>
>



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

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


Posted on the dev mailing list.