On Mon, Nov 29, 2010 at 3:41 AM, Nevo <sakur.dea...@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.mccar...@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 <j...@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 <j...@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
