[SSSD] Embedding Lua into SSSD

Michal Židek mzidek at redhat.com
Tue Aug 25 15:05:05 UTC 2015


On 08/25/2015 03:21 PM, Nikolai Kondrashov wrote:
> Hi Michal,
>
> 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/
>
> Nick

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.

Michal



More information about the sssd-devel mailing list