<br><div class="gmail_quote">On Mon, Nov 29, 2010 at 9:36 AM, Jay McCarthy <span dir="ltr">&lt;<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I really dislike such global imperative state, but it should be easy<br>
to write response/hooks or something to provide this as a library. The<br>
default response will be a streaming output though, so it will be easy<br>
to make everything efficient in extensions.<font color="#888888"><br></font></blockquote><div><br></div><div>The code is only imperative during the require phase while the hooks are registered; once done there should be no additional side effect to worry about. </div>
<div><br></div><div>The nice thing about using hooks is that it avoids the global backward incompatibility very easily - the xexpr hook can be refactored outside of the web-server module but registered by default, so it keeps existing code working, but people can switch the hooks to sxml if they so desire.  I.e. have and eat the cake at the same time ;) </div>
<div><br></div><div>To stress again, xexpr is a nice default (unless you are in the sxml camp - in which case sxml is the nice default).  Having such a default is good and simplifies tasks for people who just want to develop web pages.  From user&#39;s perspective a default means less work, and the less work the better (hence the success of Perl, Python, etc).  </div>
<div><br></div><div><div class="gmail_quote">On Mon, Nov 29, 2010 at 10:25 AM, Robby Findler <span dir="ltr">&lt;<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
This kind of thing has happened many times for other parts of the<br>system (the class system is a good example). We have generally tried<br>to avoid so much breakage and I think we should here. One technique is<br>to have a new name for the new version (or a new name for the old one<br>
if that is more appropriate; that still breaks everything but porting<br>is very easy).<font color="#888888"><br></font></blockquote><div><br></div><div>Agreed.  Industrial adaptation requires backward compatibility to be successful.  Companies such as Microsoft go to unreasonable effort to keep backward compatibility in API such as Win32, to the point of making it super cumbersome to use.  And if they need to break the compatibility they introduce a new version, but support both version going forward to still keep the backward compatibility.  </div>
<div><br></div><div>My 2 cents.  Cheers,</div><div>yc</div><div><br></div><div><br></div></div></div></div>