I love how the CAB project is working with our community process. Not only does the transaprency give us a chance to ge great input from field, customers, partners and even folks at MS product groups; but it also is a nice forcing function to keep our house in order continoususly.

We started CAB iteration 7 on Monday.  As we prep for our first code drop later this week, i was reminiscing about what feature areas we have changed so far based on our Expert Advisor team input, and on the customer developer team that flew in to sit physically with us and prototype their applications while giving us continous feedback on our CAB effort.

This list is too long to be exhaustive but here are some examples:

  • Adding more attention to shell-agnsotic modules and their architectures. I had originally envisioned that modules that built to be agnostic to the shell they are targeting would be the exception rather than the norm, and the ability to do shell-agnostic code was almost a pleasant side-effect of the initial design we had of CAB. Well, thanks to customer input this is getting a bit more attention now. CAB doesn't push you one way or the other, but we are placing a more focus on the shell-agnostic scenarios than we originally planned to.
  • Startup sequence: the initial architecture had the three main services CAB uses (Authentication, CatalogReader and ModuleLoader) as plug ins - now the bootstrap sequence itself is a plug-point as well after working with one customer who needed to inject work between loading the solution profile and actually loading the relevant modules. Now, if you put no config, "it just works" and of you start adding config you can just change the plugin implementations, or directly declare a type of your own to run the bootstrap (for advanced cases).
  • Renaming Contexts to WorkItems. It was hard for us to find a good name (Context? UseCase? Task? WorkArea? ApplicationController?) Thanks for all of those who chimed in. Again, context is such a powerful concept and metaphor, that the word can easily be misused/abused.
  • WorkItems accessing parent and children workItems now you can do (in a WorkItem class) this.WorkItems["xyz"]
  • Event Broker: The use of URIs to identify event topics and the automatic background thread attribute

This is just a sample list. We are currently working on Enterprise Library for VS.NET 2005 and we'll conduct our engineering process in a much more transparent way than what we did with EntLib v1, so hopefully that will let you plan around it (and influence our engineering) more and more often.

Today Tuesday I'm in the -other- bullpen, the EntLib one. Brad and Fernando are there, and Scott will be in any minute now. Today is our iteration planning, I have to give an entlib intro talk  (I try not to do too many talks but Ron and the devs all had to bail out last minute) and then I'm off to Seattle downtown to work with Avanade on a process by which we can have shared engineering and planning. This process is to let redistributors of p&p assets understand how to partner themselves in with our own teams work, to help them extract the most value out of our effort.