[racket-dev] Removing Xexpr preference from Web Server

This kind of thing has happened many times for other parts of the
system (the class system is a good example). We have generally tried
to avoid so much breakage and I think we should here. One technique is
to have a new name for the new version (or a new name for the old one
if that is more appropriate; that still breaks everything but porting
is very easy).

Robby

On Monday, November 29, 2010, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
> 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
> _________________________________________________
>   For list-related administrative tasks:
>   http://lists.racket-lang.org/listinfo/dev