List view
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)? https://github.com/ngocdaothanh/xitrum-scalate/issues/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
No due date•0/1 issues closed