|Hey Marc! Grats on being the boss
(Did I miss Part 1 somewhere?? Me no see it :P)
<sarcasm>AF, abstract? Nahhhh.
As I see it there is one big pitfall with an AF. IT's trying to make it do too much. I've been playing with AF ideas for over 2 years now and I've fallen into this trap too many times. The tendency is to make it do everything and the kitchen sink. What you need t remember is start with a core base set of services/functionality and let the framework evolve. Remember, the key word is abstract!
The other thing to keep in mind is that a AF does not necessarily mean plugin architecture. An AF simply is there to provide base services to something. If we want to include extensibility plugins, so be it, but let's not make their names synonymous (although I think plugins may be a foregone conclusion :P)
The last couple months, I've scrapped what I was working on and tried to come at the whole thing from the concept above. I asked myself what base services do every application I write need to have or that I am constantly asked for? What has to be down at the "Ring 0 and 1" of my application at the start and can't be bolted/added on later?
I usually come back to 4 things:
1) An ability to manage properties for the application.
2) The ability to manage resources (usually include globalization/localization in here)
3) A internal relatively simple, eas for the layman to use scripting engine of some sort allowing the user to be able to write small macros or whatever to be able to extend the application themselves without resorting to having me change them 75-150 and hour to write something that reformats someone's info or some such.
4) A distancing of the GUI elements from Data elements and those from code constructs. (Marc's idea of a DataHub, GUI manager, etc basically)
Those are my usual focuses at the start. However 1,2, and 4 are probably the most realistic. Number 3 is in there because the more I have worked with the ideas the farther I've had to push that down into the lower levels of the app design. I believe the first two are a mandatory for any framework the other two are pure architecture discussions waiting to happen.
Marc, it may be a good idea to take a survey of the team and gather a little info like what peoples strengths are, what they would be using the AF for, etc. Those questions tend to point me to where my focus wants to be on a project. Also, I hate to bring this up, but what's an AF without a sample Application? I'm not saying we rewrite SharpDevelop or something, but it will be good to have a app built on our framework to test and showoff. (I know what I want to use it for, but it is SOOOO out of scpe its not funny :P)
Just some ideas.