on this lua project, I may have something to say, we have to make another implement just because we are not satisfied with the origin one, and my team have no interesting in build from the origin one. that is sad, but that is the problem we have, which I can not solve.
the good point is, we have another one, that maybe better, and it is accepted by some of the users and Shu Kit Chan, our new committer, and the author is willing to maintain and enhance as required, good healthy project so far I can say. so, all I think that is, we(Apache Traffic Server) have a step forward. I think I agree with James, we just need someone step up and push the project forward. I must thank Shu Kit Chan for that, he make some voice when I still hesitate to speak. on this lua project, now we have more than two active developers working on it, I feel much happy on that. we do make some duplicated effort, in lua and the later spdy, you got it because ether the origin codes is not what we want, or we have our own requirements, for spdy, because we have a team working on spdylay already. maybe we should not open it in the public, so that you will have no idea of what we have done :D for the community, we have choose a very bad way, it is hard for me too. how can I provide a good solution, in 3weeks or less, with production quality? it is just a balance, and we just choose to go the other way, don’t panic if one user don’t go what we expect, that is just because we need to do better, and ATS is a free software, as in freedom :D no meter how hard we need to solve, all of the effort is denoted to the community, and ATS get the benefit, so as our users. we will show our respect to all the origin authors and the following maintainers. we are from deferent company, with deferent requirement and using case, we do have some distinguish, I realized that I can not force anyone out of my team follow my strict rules. for example the cluster, we rebuild it just because we want 4Gb and it can only archive 3Gb per box. but that is same feature, but very deferent way. I feel sorry for all those trouble we(alibaba) introduced here, we have struggled from a very hard situation, hence we do care some of the cutting edge requirement. good news is ATS can handle it :D I’d expect we make more talks on the future roadmap and solutions, to make things more easy to manage, and not so many surprise, I am feeling sorry that your guys not come to China this year, haha a bit off topic, and thanks everyone, glad to work with you to hack the ATS monster —zym 在 2013年12月18日，上午12:59，Shu Kit Chan <chanshu...@gmail.com> 写道： > Hi, > > For months, I have been trying to look for better ways to write simple > plugins. And so the existing experimental/lua is a good starting point. But > upon further investigation, it is really experimental and with not much > features. I think it is more a skeleton code for us to add on. About a few > weeks back, i read a chinese blog post and learned about the > experimental/ts_lua plugin. It is a functional and rather complete plugin. > So i worked to get it added to the source tree. > > 1) I don't think we should keep both. > 2) It will be hard to merge them, i think. > 3) There is very little that experimental/lua can do that > experimental/ts_lua cannot. I am thinking of adding some more functionality > there in experimental/ts_lua before suggesting to retire experimental/lua > 4) I was more hoping to put the code in experimental directory to stir > interests in discussions in the first place, thinking that "experimental" > may be a less intrusive place to try things out. > 5) Perhaps we can have more guidelines related to plugins and experimental > plugins if we don't already have one. That may help. e.g. What's the > criteria to put stuff in experimental directory? What's the criteria to > promote it out of "experimental"? I read some discussions in these topics > but perhaps we can have a better guidelines. > > Thanks. That's my two cents. I will be happy to help and contribute to whip > the whole situation in a better shape. > > Kit > > > On Tue, Dec 17, 2013 at 8:31 AM, Leif Hedstrom <zw...@apache.org> wrote: > >> Hi all, >> >> First, I don’t want to stir up more stuff than necessary, but I think it’s >> important that we figure out which directions we should take regarding the >> Lua plugins. I feel this has been handled somewhat unprofessional, and >> hence, I’d like to get the discussion going. We’ll undoubtedly have to deal >> with this more frequently as we gain popularity :). >> >> Here’s the issue, IMO at least: We now have two competing Lua plugins in >> the source tree. They share nothing afaik. Neither are well documented. I >> guess more code is better than less code, but I think it’s an overall >> confusing story for our users. Which of the two Lua plugins should they >> use? Which one do we expect developers to contribute to? And which one (if >> any?) gets promoted to being stable? How would we make such a decision? Do >> we make such a decision?? >> >> I’d like to open up the discussion here, a few things to consider are >> >> 1. Do we keep both? >> 2. Do we try to merge them? Is there value in merging the two code bases? >> 3. Or do we simply retire one of them? >> 4. How did we end up like this? Did our processes break at some stage >> where we ended up with two plugins for the same feature? >> 5. How do we avoid future duplication like this ? I know for example both >> PageSpeed and SPDY are at risk of similar duplication. >> 6. How do other organizations deal with this? I’m particularly curious as >> to how HTTPD deals with it. >> >> >> Please discuss. >> >> — Leif >> >> Yongming Zhao 赵永明 aka 永豪 yong...@taobao.com
