On Sat, Nov 27, 2010 at 2:39 AM, Jay McCarthy <jay.mccar...@gmail.com>wrote:
> > I've just added response/port for this purpose, although it only > provides the ability to stream the content, the headers must be > produced beforehand. Is that a game breaker? Having response/port is great. In the future it would also be great to expose the input & output port to the servlet. > I very much agree; I wonder if the single 'make-xexpr-response' will > be too much overhead. > It won't be just a single make-xexpr-response at the entry point, if the idea is to push the construction of the type of responses into the servlet, unless the servlet only deals with a single type of response. On Fri, Nov 26, 2010 at 4:55 PM, 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. > 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. My 2 cents. Cheers, yc
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev