One question we are getting is - how will offline relate to CAB? How are we making sure that an application built with both presents a consistent architecture style? Is there a dependency?

So here we go: First of all, the Offline Application Block (Offline AB) was built for VS.NET 2003, whil CAB (Composite UI AB) was designed and built for VS.NET 2005. So there is porting to do to make it .NET 2.0 friendly. Also, the feedback is that the Offline AB API, in its full OOP glory was er.. beautiful to look at but a pain to use, so there will be som façading to do there. I also beleive the original block included the Caching application block for good reasons, but maybe we should "carve out" the offline domain to work well with, but not include, the issue of reference data caching. So with 3 goals in hand - designing it for .NET 2.0, simplifying the API, and redrawing a tighter domain boundary - we roll up our sleeves and think about how to build an Offline AB v2 that is decoupled as possible from other domains.

We don't know what he result will look like yet - but here are our observations so far - please give us your comments

1) if we carve the domain with a finer scalpel the offline block could just take care of detecting the offline status, queuing messages for outgoing requests, and sending notifications that the requests were delivered back to service agents or controllers. Caching reference data is stil something that your service agent could do, but the offline block could have less intrusion into how that gets done

2) we need to decide what the storage of message data is going to be based on. I think it's important to be able to add lifetime policy to that state (expirations, dependencies, etc).

3) It is a goal of the ofline block not to depend on CAB being used for the rest of the architecture. So we are sticking to basic .NET primitives when dealing with your application,  trying to impose little to nothing on the implementation of your classes and business logic.

About this last point: There are designs that allow you to add services and semantics to your components without imposing hefty base classes, arbitrary interfaces or other intrusive dependencies. Some of these designs are based on inversion of control and dependency injection. The hard thing- the temptation- is that CAB provides an implementation of a container / injection architecture that would be oh so nice to have around in any app for use by the app itself, or app blocks. Setting a reference on CAB is a temptation we are wanting to keep away from. One way of sidestepping the issue in the short term would be to provide the offline block with its own specialized mini container, and make it compatible with CAB's. In the long run my take is that the solution should be to have such a container-injection-thing-monkey as a core library that all blocks can use.

So we do think it's important that blocks keep tackling smaller domains and remain as "orthogonal" or as independent as possible...the question is as we tackle larger sets of problems, what is the architecture, dependency, and packaging approach that will let PAG scale and continue to build domain-specific frameworks and guidance that can evlve independently and compose with those built by others? We think runtime architectures based on inversion of control and dependency injection hold a potential, and we are evaluating how those fit in the roadmap.

In the meantime, stay tuned to the Smart Client program for the imminent release of the CAB 1.0 community preview, based on VS.NET 2005 beta 2. We have had a lot of fun engaging with customers and community following our community process, and  devloped an excellent relationship with the VS.NET team. Join us for the announcement! at http://workspaces.gotdotnet.com/cab

Have a great weekend