[racket-dev] Removing Xexpr preference from Web Server

Three hours ago, Robby Findler wrote:
> On Tue, Nov 30, 2010 at 8:04 AM, Eli Barzilay <eli at barzilay.org> wrote:
> > Two hours ago, Robby Findler wrote:
> >> On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay <eli at barzilay.org> wrote:
> >> >
> >> > The problem here is that there is no name to change -- it's the
> >> > implicit "coercion" of xexpr values to a response.
> >>
> >> Why can't there be two libraries, one that coerces and one that
> >> doesn't? More generally, one that acts the same as the current
> >> library and one that is intended for new code?
> >
> > That would require a new `web-server' module, as well as a whole
> > bunch of other modules.
> 
> I know.
> 
> > Even worse, writing a module using one web server library, and
> > using it in the other won't work, since it's a dynamic property of
> > how the result is getting used.
> 
> (I think it may be possible to be creative to avoid these things being
> errors when you mix; but maybe it is better to have an error when you
> mix; I don't have a strong opinion here but I'd try to make mixing
> work so people can migrate piecemeal.)

[I don't see a way to do that.]


> As I said before, we have done this with the class system many
> times.  We have done this with other parts of the system as well
> (not as many times tho). It is not a simple thing.
> 
> That said, massive backwards incompatibility as Jay is proposing
> seems wrong.

I'll leave this Jay, but I think that there are some important points:

* Doing the same for the web server will be much more problematic
  since there are many interface modules that do the implicit
  coercion.  It looks to me like the only way to do that will be a new
  toplevel `web-server' collection.

* Even in the case of the class system, one of the transitions was
  going the other way -- renaming the old one (still available as
  `mzlib/class100') instead of having the new one under a new name.

* The fact that this is much more problematic in the web server's
  case, combined with the fact that the change itself is much more
  minor (compared to the class system changes), is -- IMO -- a strong
  indication that a backward-compatible change via a parameter is the
  right way to go (defaulting to the same as it does now).

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!