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:[email protected]] Sent: 13 June 2012 15:46 To: [email protected] 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" <[email protected]> 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!" >
