You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Cormier, Ricky" <ri...@last.fm> on 2012/06/13 10:18:44 UTC
Feedback request: Add support for luabind to thrift compiler
All,
I am one of the senior developers at last.fm. We currently have a requirement to interface with thrift services via Lua.
http://www.lua.org/
Whilst we would love to implement full and native Lua support to thrift for both compiler and libraries we just don't have the time nor the use-case. Instead, we plan to implement a parser for thrift IDL that will be able to generate Lua bindings for C++ client code using the Lua Bind library.
http://www.rasterbar.com/products/luabind.html
After giving this some thought we realised it wouldn't be too much effort for us to hook this into the existing thrift compiler as a new generator (and take advantage of the fact the IDL is already parsed out for us), which we propose to call 'luabind' (eg. -gen luabind). This would make it clear that it is generating Lua Bind C++ bindings and not native Lua. This would also still keep the door open for a native Lua implementation that could use the name 'lua' as the generator.
Before we go to the effort of hooking this into the thrift compiler (otherwise we'll probably just hoik something up in Perl) we wanted to know if there was any upstream interest in this and whether, were we to submit it, it would be accepted given:
* it'll only client-side generated bindings using Lua Bind
* It would only directly support Luabind/C++
* C support can be obtained using a C linkage C++ API
* Apart adding a new option to the compiler the code will be self-contained.
* The change wouldn't preclude native Lua support in the future
Lua is designed from the ground up to be embedded in C/C++ so whilst this isn't a native code implementation the very fact that if you're using Lua you're almost certainly going to be using C/C++ makes this a reasonable way to get thrift support via Lua that leverages existing C/C++ code.
Thanks in advance for your feedback.
Ricky Cormier
Senior Software Engineer
http://www.last.fm/user/evilrix
Last.fm
Karen House | 1-11 Baches Street | London | N1 6DL
"if it doesn't scrobble it doesn't count!"
RE: Feedback request: Add support for luabind to thrift compiler
Posted by "Cormier, Ricky" <ri...@last.fm>.
Dave,
Actually, full Lua bindings would be fine. The only reason I was planning on Luabind was just for keeping it simple.
Thank you in advance.
-----Original Message-----
From: Dave Watson [mailto:davejwatson@fb.com]
Sent: 13 June 2012 15:46
To: dev@thrift.apache.org
Subject: Re: Feedback request: Add support for luabind to thrift compiler
Hello,
Internally at Facebook a developer recently made full lua bindings. Let
me ping him and see what the state of open sourcing them is.
I believe they were full lua though, so not 100% what you are discussing
On 6/13/12 1:18 AM, "Cormier, Ricky" <ri...@last.fm> wrote:
>All,
>
>I am one of the senior developers at last.fm. We currently have a
>requirement to interface with thrift services via Lua.
>
>http://www.lua.org/
>
>Whilst we would love to implement full and native Lua support to thrift
>for both compiler and libraries we just don't have the time nor the
>use-case. Instead, we plan to implement a parser for thrift IDL that
>will be able to generate Lua bindings for C++ client code using the Lua
>Bind library.
>
>http://www.rasterbar.com/products/luabind.html
>
>After giving this some thought we realised it wouldn't be too much
>effort for us to hook this into the existing thrift compiler as a new
>generator (and take advantage of the fact the IDL is already parsed out
>for us), which we propose to call 'luabind' (eg. -gen luabind). This
>would make it clear that it is generating Lua Bind C++ bindings and not native Lua.
>This would also still keep the door open for a native Lua
>implementation that could use the name 'lua' as the generator.
>
>Before we go to the effort of hooking this into the thrift compiler
>(otherwise we'll probably just hoik something up in Perl) we wanted to
>know if there was any upstream interest in this and whether, were we to
>submit it, it would be accepted given:
>
>* it'll only client-side generated bindings using Lua Bind
>* It would only directly support Luabind/C++
>* C support can be obtained using a C linkage C++ API
>* Apart adding a new option to the compiler the code will be
>self-contained.
>* The change wouldn't preclude native Lua support in the future
>
>Lua is designed from the ground up to be embedded in C/C++ so whilst
>this isn't a native code implementation the very fact that if you're
>using Lua you're almost certainly going to be using C/C++ makes this a
>reasonable way to get thrift support via Lua that leverages existing C/C++ code.
>
>Thanks in advance for your feedback.
>
>Ricky Cormier
>Senior Software Engineer
>http://www.last.fm/user/evilrix
>
>Last.fm
>Karen House | 1-11 Baches Street | London | N1 6DL "if it doesn't
>scrobble it doesn't count!"
>
Re: Feedback request: Add support for luabind to thrift compiler
Posted by Dave Watson <da...@fb.com>.
Hello,
Internally at Facebook a developer recently made full lua bindings. Let
me ping him and see what the state of open sourcing them is.
I believe they were full lua though, so not 100% what you are discussing
On 6/13/12 1:18 AM, "Cormier, Ricky" <ri...@last.fm> wrote:
>All,
>
>I am one of the senior developers at last.fm. We currently have a
>requirement to interface with thrift services via Lua.
>
>http://www.lua.org/
>
>Whilst we would love to implement full and native Lua support to thrift
>for both compiler and libraries we just don't have the time nor the
>use-case. Instead, we plan to implement a parser for thrift IDL that will
>be able to generate Lua bindings for C++ client code using the Lua Bind
>library.
>
>http://www.rasterbar.com/products/luabind.html
>
>After giving this some thought we realised it wouldn't be too much effort
>for us to hook this into the existing thrift compiler as a new generator
>(and take advantage of the fact the IDL is already parsed out for us),
>which we propose to call 'luabind' (eg. -gen luabind). This would make it
>clear that it is generating Lua Bind C++ bindings and not native Lua.
>This would also still keep the door open for a native Lua implementation
>that could use the name 'lua' as the generator.
>
>Before we go to the effort of hooking this into the thrift compiler
>(otherwise we'll probably just hoik something up in Perl) we wanted to
>know if there was any upstream interest in this and whether, were we to
>submit it, it would be accepted given:
>
>* it'll only client-side generated bindings using Lua Bind
>* It would only directly support Luabind/C++
>* C support can be obtained using a C linkage C++ API
>* Apart adding a new option to the compiler the code will be
>self-contained.
>* The change wouldn't preclude native Lua support in the future
>
>Lua is designed from the ground up to be embedded in C/C++ so whilst this
>isn't a native code implementation the very fact that if you're using Lua
>you're almost certainly going to be using C/C++ makes this a reasonable
>way to get thrift support via Lua that leverages existing C/C++ code.
>
>Thanks in advance for your feedback.
>
>Ricky Cormier
>Senior Software Engineer
>http://www.last.fm/user/evilrix
>
>Last.fm
>Karen House | 1-11 Baches Street | London | N1 6DL
>"if it doesn't scrobble it doesn't count!"
>