Here is my current plan:<div><br></div><div>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</div> <div><br></div><div>In that directory is the attached README.</div><div><br></div><div>What do you think?</div><div><br></div><div>Jay<br><br><div class="gmail_quote">On Tue, Nov 30, 2010 at 11:14 AM, Eli Barzilay <span dir="ltr"><<a href="mailto:eli@barzilay.org">eli@barzilay.org</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Three hours ago, Robby Findler wrote:<br> > On Tue, Nov 30, 2010 at 8:04 AM, Eli Barzilay <<a href="mailto:eli@barzilay.org">eli@barzilay.org</a>> wrote:<br> > > Two hours ago, Robby Findler wrote:<br> > >> On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay <<a href="mailto:eli@barzilay.org">eli@barzilay.org</a>> wrote:<br> > >> ><br> > >> > The problem here is that there is no name to change -- it's the<br> > >> > implicit "coercion" of xexpr values to a response.<br> > >><br> > >> Why can't there be two libraries, one that coerces and one that<br> > >> doesn't? More generally, one that acts the same as the current<br> > >> library and one that is intended for new code?<br> > ><br> > > That would require a new `web-server' module, as well as a whole<br> > > bunch of other modules.<br> ><br> > I know.<br> ><br> > > Even worse, writing a module using one web server library, and<br> > > using it in the other won't work, since it's a dynamic property of<br> > > how the result is getting used.<br> ><br> > (I think it may be possible to be creative to avoid these things being<br> > errors when you mix; but maybe it is better to have an error when you<br> > mix; I don't have a strong opinion here but I'd try to make mixing<br> > work so people can migrate piecemeal.)<br> <br> </div>[I don't see a way to do that.]<br> <div class="im"><br> <br> > As I said before, we have done this with the class system many<br> > times. We have done this with other parts of the system as well<br> > (not as many times tho). It is not a simple thing.<br> ><br> > That said, massive backwards incompatibility as Jay is proposing<br> > seems wrong.<br> <br> </div>I'll leave this Jay, but I think that there are some important points:<br> <br> * Doing the same for the web server will be much more problematic<br> since there are many interface modules that do the implicit<br> coercion. It looks to me like the only way to do that will be a new<br> toplevel `web-server' collection.<br> <br> * Even in the case of the class system, one of the transitions was<br> going the other way -- renaming the old one (still available as<br> `mzlib/class100') instead of having the new one under a new name.<br> <br> * The fact that this is much more problematic in the web server's<br> case, combined with the fact that the change itself is much more<br> minor (compared to the class system changes), is -- IMO -- a strong<br> indication that a backward-compatible change via a parameter is the<br> right way to go (defaulting to the same as it does now).<br> <div><div></div><div class="h5"><br> --<br> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:<br> <a href="http://barzilay.org/" target="_blank">http://barzilay.org/</a> Maze is Life!<br> </div></div></blockquote></div><br><br clear="all"><br>-- <br>Jay McCarthy <<a href="mailto:jay@cs.byu.edu" target="_blank">jay@cs.byu.edu</a>><br>Assistant Professor / Brigham Young University<br><a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br> <br>"The glory of God is Intelligence" - D&C 93<br> </div>