Yes, perms are a major design flaw. That's been alluded to here in various posts, and Malte Sussdorf (one of my favorite ex-aD types) passed along some stern cautions regarding perms that included horrific performance numbers in regard to a bank project they worked on in Germany.
Even Philip says 4.x is incomplete and sucks, though of course he claims it is all the fault of the VCs and their lackeys, and that he bears no responsibility for this product. I don't even want to go there...
Perms need a severe re-do, this is clear. I've been thinking that this and the APM are two areas I would spend time on as the port progresses. Not alone, necessarily, but its crucial enough so I'm going to want to have my thumbs stuck deep into it.
I don't think this needs to stand in the way of the porting effort, which after all is more than anything else about building a framework that can support multiple databases. Yes, this seems a no-brainer but after the Oracle uber alles attitude held by aD for so long it seems that a proof-of-concept goal must be utmost in our minds.
I guess I mean it's not going to be *worse* than the aD-delivered version when we get to the end of this first step. After all, we'll be running their code.
I hope we'll have time to make it better before we declare victory (i.e. our first release), of course, but proving the feasibility of the multi-db approach is #1 on my priority list. That's largely because I'm very confident we can fix these weaknesses once we've got the basic toolkit framework in place. Again, hopefully that comes early enough in the process so we can redo the most gross aspects of 4.x before releasing.
And this is certainly one of them (the lack of meaningful admin stuff is another, I love the aD employee's comment in another thread about loading places and getting a list of 90,000 objects on his admin objects page!)
