[racket-dev] Removing Xexpr preference from Web Server

Here is my current plan:

Add web-server/compat/0 directory with, e.g.,
web-server/compat/0/http/response-structs to hold compatibility bindings to
bridge the old http/response-structs and the new http/response-structs

In that directory is the attached README.

What do you think?

Jay

On Tue, Nov 30, 2010 at 11:14 AM, Eli Barzilay <eli at barzilay.org> wrote:

> 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!
>



-- 
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20101203/5096c9cd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: README
Type: application/octet-stream
Size: 2682 bytes
Desc: not available
URL: <http://lists.racket-lang.org/dev/archive/attachments/20101203/5096c9cd/attachment.obj>