[racket-dev] Removing Xexpr preference from Web Server

On Sat, Dec 4, 2010 at 5:25 AM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:

>
> I think you misunderstand. Every place where there is incompatibility
> listed in the README is solved by putting a call to response/xexpr rather
> than returning an Xexpr. The file just lays out all the places where you may
> need to put those calls. Almost all of those places are internal plumbing
> places that I don't observe people using in practice [especially the ones
> which I haven't provided compatible bindings for [except for
> web-server/insta]]
>

Reading it again I realize that my concern is that I cannot discern what I
need to do to keep compatibility from the doc alone and that had me
concerned.  I probably should have waited to read it again in the morning
before sending out an email.

Question: what does all the "removed" binding mean?  For example,
response/basic, response/incremental, etc are all removed.  Are these kept
in the compatibility layer and the removed mean that they are removed from
the old version?

I'm not convinced that a parallel version will be any different than a user
> staying with an old version or taking the directory from the old version and
> putting it in the new version.
>

If users stay with an old version because of this wouldn't that defeat the
purpose of making a new release?  Also I would not expect users to manually
copy the old web-server and put it into the new version, because such change
means they are shackled to their own customization of the platform, which
will break when the platform is yet upgraded again.


> I think the difference is that those are languages where you want
> interoperability between ported programs and yet-to-be ported. In contrast,
> even though you can split a Web app into many servlets and many modules per
> servlet, I don't observe people using multiple servlets [which would be able
> to be ported separately]; and if you tried to just port some modules of a
> many-module servlet, it simply wouldn't work with parallel version because
> there would be, for example, two incompatible request data structures
> because they are generative.
>

Having the old language available means users do not have to port the code
at all.  That's the path to least resistance toward an upgrade.  My C code
written 10 years ago still compiles on new compilers today without me having
to fix anything, and that gives me the confidence as an user that I can
upgrade to the latest and greatest version, and I can sell those code to
whoever wanting to buy them without any fuss on my part.

With regards to web-app, people might not write multiple servlets, but if
their app is of any complexity (most web apps I know are complex) they will
call many other modules to do the work, and that means they might want to
write newer modules with newer version of racket because of a new features
are being offered (or a critical bug fix being available).  But they likely
will want to focus their energy on taking advantage of that new feature,
instead of having to fix their servlet because of compatibility.

Having said that, I am not saying compatibility can never be broken - just
that it always comes at a cost.  So the users need to be enticed to an
upgrade with promise of better functionality, supported with an upgrade
path, and perhaps enforced with a grace period of obsolescence.

In this specific case, I am not sure what users will gain with the
refactoring.  I know what it gains architecturally, but the benefits for
users have not been articulated.  Cuz again, xexpr is a good default format,
and users should have a default format instead of having to always make a
response explicitly.  It feels like the users have lost a benefit.

Thanks Jay for putting this up through a vetting process.  Although my
opinion appears to differ from yours, I want to ensure you know that I
appreciate you doing this, as it shows that you value users' input and put
the concern of compatibility high.  My perspective comes from an industry
user and lib writer, and I harbor the hope that racket can achieve that
escape velocity perl/python/etc enjoyed, so I constantly apply industry
expectations here, which might not be fair yet, since that might not be a
goal of the racket team, but I can hope can't I ;)

Anyhow - just my 2 cents as usual.  Cheers,
yc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20101204/6dfca474/attachment.html>