[Freeipa-devel] Command instantiation

[Simo Sorce]

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 ?

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

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York