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