[Freeipa-devel] Command instantiation

[Petr Viktorin]

On 01/15/2013 02:39 PM, Simo Sorce wrote:
> On Tue, 2013-01-15 at 10:23 +0100, Petr Viktorin wrote:
>> On 01/14/2013 08:45 PM, John Dennis wrote:
>>> On 01/14/2013 12:56 PM, Jan Cholasta wrote:
>>>> On 14.1.2013 18:50, Petr Viktorin wrote:
>>>>> Ah, yes, you've discovered my ultimate goal: rewriting the whole
>>>>> framefork :)
>>>>
>>>> It would seem we share the same ultimate goal, sir! :-)
>>>
>>> Well it's reassuring I'm not alone in my frustration with elements of
>>> the framework. I thought it was just me :-)
>>>
>>> I have one other general complaint about the framework:
>>>
>>> Too much magic!
>>>
>>> What do I mean by magic? Things which spring into existence at run time
>>> for which there is no static definition. I've spent (wasted) significant
>>> amounts of time trying to figure out how something gets instantiated and
>>> initialized. These things don't exist in the static code, you can't
>>> search for them because they are synthetic. You can see these things
>>> being referenced but you'll never find a class definition or __init__()
>>> method or assignment to a specific object attribute. It's all very very
>>> clever but at the same time very obscure. If you just use the framework
>>> in a cookie-cutter fashion this has probably never bothered you, but if
>>> you have modify what the framework provides it can be difficult.
>>>
>>> But I don't want to carp on the framework too much without giving credit
>>> to Jason first. His mandate was to produce a pluggable framework that
>>> was robust, extensible, and supported easy plugin authorship. Jason was
>>> dedicated, almost maniacal in his attention to detail and best
>>> practices. He also had to design most of this himself (the rest of the
>>> team was heads down on other things at the time). It has mostly stood
>>> the test of time. It's pretty hard to anticipate the pain points, that's
>>> something only experience with system can give you down the road, which
>>> is where we find ourselves now.
>>>
>>
>> +1.
>> It's easy to criticize in hindsight, and I have great respect for the
>> framework and its author.
>> Nevertheless, software grows over time and we need to balance bolting
>> things on with improving the foundations, so that we don't get stuck in
>> a maze of workarounds in a few years.
>
>
> Can someone summarize how big a change this would be ?
> I do understand the general discussion, but I have not been involved
> deeply enough in the framework code to tell.
> Also how much would this conflict with the proposed LDAP change ?

No, the LDAP changes won't affect the framework nor the plugin code.

> Do we have a way to slowly change stuff or will it require big
> all-or-nothing changes ?

As far as I can tell without trying it, the change wouldn't be too 
disruptive.
Command is now immutable, so to current code it shouldn't matter if 
api.Command.xyz returns a "global" instance or a freshly created one.
There will be some complexity to make the change only for Commands and 
not the other plugin types, but it shouldn't be a big change.
The next step is to not lock the Command class. Again I think the 
biggest issue will be to disable the locking only for Commands and not 
other classes in the hierarchy.

When that's done, we can gradually change individual commands to store 
data in the Command object. I'd do one or two to make sure the approach 
works, after that it would be a series of small, localized, low priority 
patches. The main benefit is that *future* code wouldn't have to resort 
to thread-local storage.

-- 
Petr³