On (25/08/15 19:45), Nikolai Kondrashov wrote:
On 08/25/2015 06:59 PM, Lukas Slebodnik wrote:
>On (25/08/15 15:57), Nikolai Kondrashov wrote:
>>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.
>>
>SSSD is written in asynchronous way and tightly coupled with tevent[1] and
>talloc. This is not use case for using scripting language. The ideal use
>case for scripting languages is to write higly optimized library in C +
>bindings. The scipting language would be used for replacing boilerplate code
>in C. However there are still few ways. You can write simple example of
>using lua scripts with tevent[1]. Then we can evaluate pros and cons of
>using Lua.
Now we're talking specifics, awesome! Alright, perhaps I'll do that. Care to
give a use case I should try to implement?
>The another way would be to replace tevent[1] with lua implementation of event loop.
>In another words, rewrite sssd from scratch.
Whoa, no way :)
>>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.
>>
>Providers are very complicated due to compicated servers (LDAP, IPA, AD)
>We will not be able to replace high level iplementation with scripting language
>in short time (Lua -> C) . In short time, there still will need to be two way
>comunication between C and Lua (Lua <-> C). Which would not be simplify code as
>the first way.
Sure. It's complicated. That's why a higher level language might be
beneficial. If we can cut off some parts of a provider cleanly (which is a
good idea for refactoring anyway), we can reimplement them in Lua with
relatively low overhead. Thus, going by pieces we can reduce the disruption.
We separated logic to small parts with tevent style.
* create request
* do staff
* register callback
* call callback after finishing asynchronous operation.
If we want to use tevent + lua there might not be a huge saving in LOC;
You safe few lines with lua code, but you add extra lines for bingins to
wrap tevent request. Maybe it would help to write some example.
BTW you might find simple example of tevent style in libtevent (samba) itself.
It might be faster way then extracting LDAP example from sssd.
>>I expect main savings to come from
>>exception support,
>scripting language might help
>
>>automatic memory management,
>talloc helps a lot even in C.
I agree. Still, it's explicit and needs taking care of, constantly.
Yes, but there is a huge simplification with hierachical allocator
+ registering destructors for complicated stuff.
So memory management is not a benefit.
>>simpler data massaging,
>What do you mean here?
The messy stuff. Parsing and gluing strings together, maintaining complicated
data structures, converting from one representation to another, etc.
Agree.
BTW gluing strings together is not very compicated with
talloc_asprintf; however parsing strings would be a much nicer.
>>and brevity of a scripting language (e.g. implicit, dynamic
typing).
>>
>This can be pros and cons in the same time.
Implicit, dynamic typing - yes. Brevity - not likely. You can always make it
more verbose, after all, but it is hard the other way around.
>Summary:
>This is an interesting idea; but currently I cannot see many benefits
>for using any scripting language in SSSD.
I'm careful about this as well. Yet, it is exciting :)
>Moreover sssd is a security service. Such step could cause problems with
>security certifications.
Well, I know little of certification, and I'm worried about security too,
however, would C be safer, really?
Do you anticipate any specific security problems?
I do not have anything specific;
It's just key factor which shoudl be considered for
such step as using scripting language in sssd.
You can write secure code even in C.
https://docs.fedoraproject.org/en-US/Fedora_Security_Team/1/html/Defensiv...
LS