[racket-dev] Removing Xexpr preference from Web Server

On Mon, Nov 29, 2010 at 9:36 AM, Jay McCarthy <jay.mccarthy at gmail.com>wrote:

> I really dislike such global imperative state, but it should be easy
> to write response/hooks or something to provide this as a library. The
> default response will be a streaming output though, so it will be easy
> to make everything efficient in extensions.
>

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.

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 ;)

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's
perspective a default means less work, and the less work the better (hence
the success of Perl, Python, etc).

On Mon, Nov 29, 2010 at 10:25 AM, Robby Findler <robby at eecs.northwestern.edu
> 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).
>

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.

My 2 cents.  Cheers,
yc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20101129/7dfb0e6a/attachment.html>