Hi Simo,
On 08/21/2015 09:37 PM, Simo Sorce wrote:
On Fri, 2015-08-21 at 20:01 +0300, Nikolai Kondrashov wrote:
> I might be in a strange and careless mood today, but here is something I
> wanted to suggest since the time I saw the amount of logic that goes into SSSD
> and is implemented in C.
>
> What if we implement some of the complicated logic inside SSSD in Lua [1]?
can you provide an example of a piece of SSSD youd replace with Lua ?
I am not asking for an implementation but a high level view of what a
function looks like to day and what it would look like if we were going
to use Lua (ideally with a list of primitives we'd still need to
provide, to understand how much code Lua replaces for real.
I don't have enough knowledge of SSSD to provide really meaningful examples.
I have to know developer pain points to really suggest an interesting
solution, and I have to really know the code to show good examples.
I don't have the time now to really dive into the code and give a good answer,
I'm sorry. If there's interest and support for this idea, I will be glad to
dig in, give you more, and help with coding and design if it comes to that.
Still, judging from the code distribution and overall architecture, I would
say the first candidates will be providers. They are very complicated and have
a relatively well defined interface to SSSD core. Most of them talk over
network and any slowdown from Lua will likely be swamped by network latency.
I would make a (partial?) adaptor from the current interface to Lua, allowing
implementing a (limited?) provider in Lua, plus low-level communication
libraries underneath. This will allow testing the feasibility without
disrupting the existing providers.
If the idea proves useful, existing providers can be re-implemented in Lua,
perhaps section-by-section, and starting from the smallest. If all the
providers are converted, the adaptor can be removed and the core will talk
directly to high-level Lua provider code. One side-effect of such work will
be refactoring and simplifying of the provider interface, which will have a
positive effect on the overall architecture.
I expect main savings to come from exception support, automatic memory
management, simpler data massaging, and brevity of a scripting language (e.g.
implicit, dynamic typing).
Nick