Re: [racket-dev] Removing Xexpr preference from Web Server
On 28 November 2010 00:31, YC yinso.c...@gmail.com wrote: I agree with Neil that xexpr or sxml are very nice representations of html as well. Given their inherent advantage I think an extensible response mechanism might work better: 1. create hooks to handle different response types 2. let the different package to install the necessary hooks For example - the hook might be called make-response-hook, and in xml package (maybe xml/web-server.ss) can install the hook. Such a hook will allow others to make their own extension as well to manage their own custom response types. Agree! that way the Racket web server seems be able to be widely proliferated, and I can handily make a call to that extension instead of converting back and forth . For example, right now, I have to first convert a list to json object, then to byte string before sending out. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Hi Jay: I have a question as to what you refer as backwards incompatible. 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 - DC 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
Re: [racket-dev] Removing Xexpr preference from Web Server
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 - DC 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 - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [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.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 - DC 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 - DC 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
