Big features:
https://groups.google.com/forum/#!topic/xitrum-framework/-8iK4mIBBQg

Rewrite to base on http4s instead of Netty?
http://http4s.org/

chill-akka

Optimize xitrum-scalate by writing directly to Netty's ByteBuf (response.content)?
xitrum-framework/xitrum-scalate#8
Also try to improve/remove ByteBufUtil.

Make Scalatags default, instead of Scalate?

More idea:

• http://www.quora.com/Startups/What-are-some-common-architectural-design-flaws-at-the-early-stages-of-a-website-which-might-later-make-it-difficult-to-scale
• http://normanmaurer.me/presentations/2014-facebook-eng-netty/slides.html
• Play 2.x Roadmap: https://docs.google.com/document/d/11sVi1-REAIDFVHvwBrfRt1uXkBzROHQYgmcZNGJtDnA/pub

MQTT:
http://netty.io/news/2014/07/04/4-1-0-Beta1.html
http://mobilebit.wordpress.com/2013/05/03/rest-is-for-sleeping-mqtt-is-for-mobile/
https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920
http://stackoverflow.com/questions/7129821/mqtt-vs-xmpp-which-should-i-choose

There are actually quite a few hacks already in Rails for Internet Explorer. I think most users expect Rails to make Internet Explorer behave as expected, without having to understand the problems that give rise to the issues in question, as long as we don't resort to sniffing IE in particular.

IE hacks already in Rails:

Rails modifies original_filename on uploaded file objects to hack around a bug where Internet Explorer was giving full Windows file paths
Files sent via send_file set Content-Type to application/octet-stream to work around quirks in IE involving SSL
Files sent via send_file set Cache-Control to "private" because the default "no-cache" broke the open/save dialog
HTTP authentication handles a case in IE where the URL sent in the Authorization header is absolute (containing http:// etc)
We also handle (by default) a quirk in some versions of Safari in which it sends a trailing null character at the end of params, and another in which it does not correctly handle an empty body (so we send " " for render :text => :none)

Rails has always handled weird Internet Explorer quirks, because (like when using a JavaScript library), Rails users don't even want to know that these problems exist. If they had to wait until the first time a user reported a bug with a file download, research it, and find the Rails plugin that patched the cache headers, they would be (correctly) quite frustrated.

Again, the line that I personally draw is that we don't fix any user-agent bugs that absolutely require sniffing. Otherwise, making the vast majority of both Rails developers and users of applications written in Rails blissfully unaware of Internet Explorer quirks is what we're here for.

-- wycats