[SSSD] Embedding Lua into SSSD

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Tue Aug 25 15:44:45 UTC 2015


On 08/25/2015 06:05 PM, Michal Židek wrote:
> On 08/25/2015 03:21 PM, Nikolai Kondrashov wrote:
>> On 08/24/2015 05:06 PM, Michal Židek wrote:
>>> On 08/21/2015 07:01 PM, 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]?
>>>
>>> I may be too conservative here, but I believe SSSD should be written in
>>> language with static type-checking at least as strong as C.
>>
>> I agree that C's static typing is very useful, even though C also requires
>> implicit typing bringing verbosity. Still, using Lua is a tradeoff. We can
>> trade static typing for the benefits Lua brings, which mostly boil down to
>> smaller, clearer code.
>>
>> BTW, a while ago I read a good treatise on the topic, which I'm happy to
>> share:
>>
>>      https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
>
> Before we use Lua (or any additional language) we need to do some
> major refactoring inside SSSD. Create internal libraries with clean
> API that operates on defined levels of abstraction for every bigger
> component in SSSD (like responders, providers, sysdb etc.) and than
> re-implement these components using the language of choice and
> these libraries (libraries would still be in C).
>
> Even if the language of choice for the higher level components
> remains to be C, such refactoring will IMO sooner or later be
> needed. However it will be a *very* big task and we would need
> to plan how to deliver such change into SSSD.
>
> Internally in SSSD we are far from clean APIs. It partially
> may be because we use C on all levels of abstractions which
> sometimes leads to their unwanted merging. We sometimes use
> structures from lower levels too high in the stack or mix the
> parts in all directions to simply make stuff work somehow
> and do not always think about clean design. Using more abstract
> language for upper (or top) layers may help to fight this
> issue a little, but the main issue is still bad API
> of the internal libraries and their unclear position in the
> stack. Once we fix these issues we can start thinking
> about adopting new language into the project but the
> possibility is that it will no longer be such an issue at
> that point.
>
> Anyway, I think you raised a good topic to think about.

Thank you, Michal. I agree that sssd is very much in need of refactoring and
once we'll have it done, the code will be easier to read and understand.

However, it will still be C, with all the associated overhead for the high
level code. Also, it will stay C. Refactoring never ends, it's like weeding
out a garden. So, we'll have to refactor C again and again.

If the target of refactoring is written in a more suitable language, it will
be that bit more pleasant and effective, and subsequent refactoring will be
easier as well.

Although, I suspect once/if we get a more powerful tool, we'll simply use it
to build a more complex system and will be back to square one, but at least
we'll get more features done :)

Nick



More information about the sssd-devel mailing list