<br><div class="gmail_quote">On Sat, Dec 4, 2010 at 5:25 AM, Jay McCarthy <span dir="ltr"><<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><div class="gmail_quote"><div>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]]</div>
</div></blockquote><div><br></div><div>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. </div>
<div><br></div><div>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? </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><div>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. </div>
</div></div></blockquote><div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div></div><div>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.</div>
</div></blockquote><div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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 ;) </div>
<div><br></div><div>Anyhow - just my 2 cents as usual. Cheers,</div><div>yc</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>