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.mccar...@gmail.com> wrote: > 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 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev