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³
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
