On 11/05/2012, at 10:21 AM, James Peach wrote:
>
> On May 11, 2012, at 8:56 AM, Leif Hedstrom wrote:
>
>> On 5/10/12 10:21 PM, James Peach wrote:
>>> Hi all,
>>>
>>> I just committed a prototype remap plugin to the jpeach/lua branch that
>>> lets you write remap plugins in Lua. I'd say it's at proof of concept
>>> stage. It seems to basically work but it's never taken any real load. The
>>> error handling is pretty lackadaisical.
>>>
>>> Here's an example that should give you a feel:
>>>
>>>
>>> <https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=blob_plain;f=plugins/lua/example.lua;hb=jpeach/lua>
>>
>> Very cool. It's actually pretty fast too. An extremely simple plugin. such as
>>
>> function remap(request)
>> url = request:url()
>> url.host = "origin.example.com"
>> url.path = "a/new/prefix" .. url.path
>>
>> request:rewrite(url)
>> end
>>
>>
>> Is only about 30% less throughput (but about 80% higher latency) compared to
>> a static remap.config rule. Pretty reasonable though (that's over 100,000
>> req / sec with that Lua code).. Once the Lua code gets more complex, LuaJit
>> would be cool too :).
>
> That sounds promising. It would be interesting to profile whether we are
> spending more time in the plugin binding or in the Lua environment. If it's
> the latter, then I think that we can change the build system to automatically
> use LuaJIT if it's available.
>
>>> I'd appreciate any comments about the API and the general approach. I think
>>> the most controversial aspect is that the plugin does not explicitly choose
>>> whether the remap evaluation chain continues. Request redirects and
>>> rejections terminate the chain; anything else allows it to continue.
>>
>> Yeah, lets gets some mileage and tests with this version, and have some
>> discussions. Should we perhaps add a CWiki page, documenting the current
>> APIs and decisions, and add proposals for additions / changes there ?
>
> https://cwiki.apache.org/confluence/display/TS/Lua+Plugin+API
>
>>> It's not clear to me yet how to extend the remap case to the general plugin
>>> case. Is the remap plugin useful enough to stand on it's own?
>>
>> Yeah, it's a whole different beast. A remap API is good to start with.
>
> As we work on the full Lua API, are we really gonna need the remap one as
> well? Since you can do remapping in a full plugin, maybe having a special
> plugin type just for remapping is unnecessary. In the C API it probably makes
> more sense because it's a much simplified model.
I thought a bit more about how the remap and full APIs can be supported.
Currently the remap plugin looks for global functions called 'init' and 'remap'
respectively.
We don't really need 'init' because you can just run code at global scope when
the source file is loaded; so 'init' can go away. I think that the global
'remap' function can go away too in favour of explicitly registering a remap
callback, eg.
TS.remap(function(request) {
-- do stuff here
})
This will match the hook function that I'm thinking of, eg:
TS.hook(TS.HttpReadRequestHeader, function(foo1, foo2) {
-- do stuff here
})
Thoughts?
