@cxshun 现在弄Play的都走啦，只有我啦，而且我们公司其他人很瞧不起Play，不过我看他们是理解不到精髓哈哈。

@lichgo 我又知道了个新的框架，谢啦，不过不会写Node。

@lichgo 我觉得简单，快，编译我倒不觉的是很大的问题，编译慢的时候可以起来走走，而且增量编译也不慢。

@pythonee 您得引入一个中间Actor来做这个事情

再用，很好用，很流畅。等isis。
我笔记本的唯一系统，工作娱乐都用这个。
当然打游戏还是用的台式机，Win7

@jinmingjian
1,我倒不是说您在造更好的轮子不妥，而是目前别人的轮子修修补补您也可以发现更多的问题，所以如果你有空，可以提交下PR，按照别人的思路，在别人的工作上改进，而不是推倒。

2,Trustin那人可行吧，但是我感觉他不喜欢别人觉得比他聪明。您可以看下他目前Netty 还是Open的Issue，然后您可以试着关闭下Issue，也就是提交PR，还有呢我觉得还是不要介意别人没有回复您的邮件好，当初我问了很傻比的InstanseOf的性能别人都回复了，所以我觉得应该不是太大的问题，如果别人忘了回复邮件或者其他的通信方式，完全没必要介意，毕竟开发者不是他一个很多人都有合并权限的。

3,的确可以做得更好，但是妹的，又是房贷又是老婆孩子，还得有自己的生活吧，所以，时间的投入可能的确不如别人，加之整个环境，所以国内的开源难做和很多其他的事情一样

4,我不是说不应该破旧立新，而是说在破之初，可以有不同的切入点，比如您现在的这个项目，知道的人不多，你可以将您的独特思考以及共享回馈到目前的主流项目，这样也可一石二鸟，多方受益。Undertow我没用，但是Play换到Spray有多个原因，1,Spray用的Scala和AKKA，2,他们好管理以前不好管的线程池，3,他们收购了Spray，但是目前不也没用么，Akka-http在Akka2.4的时候肯定还是实验班，而到akka2.5的时候还不知道究竟如何，何况Akka的ReactiveStream也还没出来，Play项目负责人也说了，可能会提供一个抽象层，Netty和Akka两套Backend。他们目前没换，也说得很清楚，要等到他们的至少和Netty的差不多了再说。他们还是把他们的一些改进合并到了上游，比如HashWheelTimer以及目前对Async-Http-Client的改进，都是合并到了上游的，当然这和你这个不同，因为您另起炉灶，和他们用别人的改进别人的还是不一样的。

5,可能他家的Bytebuf在DirectBytebuffer上的分配不如您的，不过别人的还是很好用的，我看您的接口时Bytebuffer，但是不是JDK的bytebuffer，建议呢就是还是适配大家目前已知的东西比较好，当然这个是个设计上的考量。我倒是不会提交测试代码，因为我自己也没兴趣，现在机器便宜了，可能多个机器的收益更好，更需要考量的是这个框架好用否。

6,其实直白的文字来说，更容易引起大家的共鸣，将复杂的问题用简单的方式讲出来才是高手，他那个简单的PPT不是说他肚子里面就只有那么多墨水，而是他给我们普通的开发者，或者新手在很短的时间内接触和了解netty的机会。比如几分钟内介绍您这个框架如何好，为什幺采用，如果能够打动人，那么就是真的厉害，不是么？一个好的PPT可以煽动人的。


7,我倒不是喜欢Akka的Actor模型，但是它的确让我有醍醐灌顶的感觉。并发的几个思路也不多对吧，多看点，思路也更开阔点，比如Go的http://en.wikipedia.org/wiki/Communicating_sequential_processes 和Akka 的 http://en.wikipedia.org/wiki/Actor_model
都是不同的思路，而且目前Akka加了Eventsource也就是Akka-persistence，我觉得也可以引发更多的思考，对于我们单个开发者来说，可能我们不会用也不会深入某些技术，因为精力有限，但是学习下别人思考和解决问题的思路的确对自身还是有很大的启发，我目前还没有遇到很奇葩的问题，也就是通过别人提供的解决方案没法实现的，所以思考的少，但是如果遇到了，我会去Group 问的。

8,最后的建议就是，做减法，永远比做加法难，愿你的框架做到极致。

@jinmingjian 楼主对发版本的想法可以用一句话来形容：“不鸣则已，一鸣惊人！”还有那个HttpCodec的ThreadLocalPool，我直接感觉和Play-java的HttpContext差不多了，都这么用，不过TL是有消耗的，真的可以优化。而且您的ByteBuffer提供的功能的确不多，以及您也没有按NIO的方式来实现Native。
当然我看到的都是您的老代码了，支持了。

还有一点
```
异步是很关键的，也是框架是否高效的一个重点。很多框架并不在意这一点，这里很多原因，我希望有时间我可以具体写写什么会这样，以及可以怎么样。
```
异步不一定是高效，这里逻辑有点点。。。

@jinmingjian
1,google group我这里是打了Host补丁的，不过还是会遇到偶尔访问速度啊，或者其他的一些问题
2,netty的Codec的好的地方是他又很多常见的Codec，也很好扩展，如果您要推广，那么肯定得多写几个常见的Codec
3,netty的Bytebuf主要是在Iobuffer的时候使用，快很多。有个Netty Best Practices with Norman Maurer.mp4,在Youtube上，您可以看下。
4,如果Netty的Allocator有明显的缺陷，我想如果您提交下补丁可能对国内那么多用Netty的人是个帮助，也是个好的切入点，印证了“我想改进Netty这个轮子，我也改进了，但是我打算制造一个更好的轮子”。
5,的确打算用FJ，不过既然不是银弹，所以还有其他要考虑的地方，线程模型的确是非常难的。
6,好吧，您觉得有竞争我就没办法了，但是我建议您有个更开放的心态，Netty没有开放出来的，只有部分的Codec，但是基础代码是开放出来的，我想如果您以一个开放的更加包容的心态来弄的化，可能更好，当然如果您可以狠狠的鄙视Trustin和Norman一把，那么我们也算沾光啦。就目前我已经很少使用Netty了，而是采用的Akka+play来做，因为开源，以及开放的开发，可以更好的参与以及获取项目的最新进展，您的东西的确好，但是大家看不到，我昨晚花了时间把您的Google Group的帖子看完了，也大概浏览了下代码，帖子写的很好，但是代码吧，至少写法上不是很规范，注释掉的代码没有清除掉，没有开头的声明也没有太多的注释，所以对于想要一窥的人来说，可能也是多少有点不太方便吧。
7，不管怎么样，我还是很关注和支持的，但是我还是觉得，您给Netty发下PR可能可以获取更多的关注。

话说您可以用您的框架做个类似V2ex的网站来作为您的Group，google group的访问的确不行。一方面可以证明您的框架OK，另一方面也可以有新的思路。

```
除了通用IO线程池方案，并无明显优化，
```
还有这个，因为NIO的JDK实现是有锁的，所以他们写了个Native的，然后里面没有锁，因为他们的线程模型保证了不会竞争，所以在Native的实现里面没有锁，也算个优化吧，还有全新的Bytebuf也算吧,codec也优化了。

```
最新的ByteBuf分配器使用同步关键字作为全局池访问的同步机制，在多线程测试中效率低下。
```
这个需要更正下就是目前已经改进了，每个线程有自己的池，自己没有了才去全局池，才需要同步下。

您的官网要翻墙才可以出去，在看您的官网，不过您网上说的techempower的跑分，我倒是没看到您的landz。。

@jinmingjian 您好，我很熟悉您这个头像，您的英语很好，涉猎很广也很深入，我看过您在netty的一个Issue上的讨论，很透彻。
我也给Netty提交过代码，对于您的框架，我觉得如果要开源参与，那么至少先得开源，然后作者自己很积极，同时提供更好的文档以及贡献代码的规范以及您的设计思路和里程碑。
再者还要有良好的Issue管理以及审核标准，同时要提供良好的列子程序。

如果您想建立一番不同，那么肯定是得下一番功夫，包括代码质量以及社区，特别是社区，得靠经营的，而经营社区可能比写代码更难。


Netty 以及Spray我觉得时比较具有代表性的，但是看来您的理想是做个类似Play但是比Play更加强大的框架，我相信您肯定可以做到，但是一个人的能力和精力都是有限的，可能群体的智慧更加强大。

目前Netty4比Netty3改进了不少，比如更好的ByteBuf以及更好的线程模型，以及更少的GC。而且还开始通过JNI来提升部分地方，Netty的Codec的确是需要学习和借鉴的地方。对于Spray，您也知道性能并不差，现在又合并到Typesafe啦，马上作为Akka-http发布，会更加的牛逼起来。

目前您在Github上的z-stack
https://github.com/landz/z-stack
最后的提交已是两个月前的事情了，没有很好的Dev Guide以及User Guide，WIKI页也还差点，Issue的管理也有点松散。

还有一句话有舍有得，如果您的框架可以全部开源，相信在初期可能您没什么好处，但是群体是会扩大的，也会有人慢慢的参与进来，当然您损失了您的代码，但是在后面，您会得到足够的光环的，这就是您的得。

还有一点非常重要，如果想要成功，您必须要让您的框架简单，简单和高级的特性都好用，良好的文档，例子以及社区，感谢分享这么多东西，祝您成功，如果Github放更多的东西出来，相信慢慢参与的人就会多了，还有，您可以推送您的sample到techempower，相信会发光的。

注意身体

@gaicitadie golang不会吧。

@sharpnk Play用的人还不少嘛，我们公司就我一人在用，不过很好用，他们不屑一顾。

linux brew
@dorentus

homebrew/versions/gcc43 homebrew/versions/gcc46 homebrew/versions/gcc48 homebrew/versions/llvm-gcc28
homebrew/versions/gcc44 homebrew/versions/gcc47 homebrew/versions/gcc49 homebrew/dupes/apple-gcc42
homebrew/versions/gcc45