trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <jpe...@apache.org>
Subject Re: experimental/lua vs experimental/ts_lua
Date Tue, 17 Dec 2013 17:27:52 GMT
On Dec 17, 2013, at 8:59 AM, Shu Kit Chan <chanshukit@gmail.com> wrote:

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

Agreed.

> 2) It will be hard to merge them, i think.

Agreed.

> 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

I generally agree with this too. ts_lua clearly has a larger API surface and there's not a
lot of point porting that back to the lua plugin. I think that the lua plugin has a nicer
API and module reloading works.

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

Well that was exactly the reasoning that caused me to write the lua plugin in the first place.
There seemed to be a lot of interest, so I wrote the basic mechanism and pushed what I felt
was the minimum useful plugin. There was some interest from the user community, but none from
the developer community.

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

Promoting plugins to stable was discussed here <http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201209.mbox/%3cC8A734D5-6BBA-4619-964F-A0923C23E804@apache.org%3e>,
and I think that the consensus was that these criteria are ok.

> Thanks. That's my two cents. I will be happy to help and contribute to whip
> the whole situation in a better shape.

IMHO the most important thing is maintainership. If someone cares and is willing to make the
effort to clean this up and maintain the end result, that person gets to make the decisions.
I'll support whoever steps up to maintain a Lua plugin.

> 
> Kit
> 
> 
> On Tue, Dec 17, 2013 at 8:31 AM, Leif Hedstrom <zwoop@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
>> 
>> 


Mime
View raw message