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 > >
