Yesterday, Robby Findler wrote:
> 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).
The problem here is that there is no name to change -- it's the
implicit "coercion" of xexpr values to a response.
On Saturday, Jay McCarthy wrote:
>
> I very much agree; I wonder if the single 'make-xexpr-response' will
> be too much overhead.
For the actual choice between the different representations, I think
that it's enough to have one knob -- a "translation" function that
takes in the content representation and converts it into a byte string
(or maybe a list of them), or into a thunk that will be called with
the current output going over the wire (and doing this implies chunked
output).
[Putting this knob on a parameter sounds a little bad in that it's
global state, but it seems like a good way to maintain backward
compatibility... Maybe have it default to a function that throws an
error to make it less popular?]
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
