Smart Client Offline App Block

Topics: CAB & Smart Client Software Factory
May 19, 2005 at 10:13 AM
originally posted by: AlexFed


Are there any plans to release an application block with the functionality similar to that of the old Smart Client Offline Application Block?

May 20, 2005 at 12:43 PM
originally posted by: eugeniop

We have plans to update this block. Main goals are .NET 2.0 adoption, Enterprise Libarry specification compliance and simplification. It is not related to CAB effort though.

We don't have detailed plans yet.
May 21, 2005 at 9:34 AM
originally posted by: AlexFed


Thank you for the answer.
May 24, 2005 at 4:19 AM
originally posted by: headlam

Eugenio, regardless of the changes you make. It would still be possible to integrate Smart Client Application Block into a CAB-based application. Correct?
May 24, 2005 at 8:15 AM
originally posted by: AlexFed

I second this question. Also, here at our company we are very interested in implementing a service-oriented approach just like the one from the old Offline Application Block - with caching and queueing, but in compliance and integration with the Enterprise Library.

Is this something worth investing into? Can you please post your thoughts regarding this kind of the solution? Thank you in advance.
May 25, 2005 at 6:56 AM
originally posted by: EdJez

Yes, the goal of the CAB is to provide the host/shell architecture for smart client applications, including those that work offline.

Although we haven't yet finalized the design of the offline block (which most probably will include the reusable runtime code and codegen templates for your service agents) it is paramount that it works well within a CAB-based application.

I have a question for you about this that will help us in our planning, however:
The CAB features can be used more or less independently depending on the needs of the app (i.e. you could use CAB w/out taking advantage of the module-loading features, or without using shared state or the event broker, etc) It is a good design practice to decouple the domains when they are independent, but in this case we have an opportunity: the * implementation* of the offline apps using the block could become simpler if the apps are using CAB.

I would prefer to -not- have a dependency from the offline block to CAB, or to minimize the places where that dependency may exist (of course they still would work together, it's just that they wouldn't need each other), but how important is this to you? Assuming they will work together, is a dependency an important factor for you? How important is it for PAG to build offline so that it works outside of hosts that provide CAB-ish features?

(I know I'm asking this in the CAB community board :) )
May 25, 2005 at 5:30 PM
originally posted by: AlexFed


I agree with you: Ideally, it is preferable not to have the dependency at all. In reality - the dependency is somewhat important; it becomes less important if the amount of efforts required to develop an offline application block that is 100 per cent independent from CAB grows dramatically. Our concern here is that if the two blocks depend on each other, the application framework (I might call it shell as well) we are developing here will become too stiff architecturally. So, if we are asked to vote tonight, our hearts and votes would go for the offline app block that works outside of hosts that provide CAB-ish features. On the other hand, my instincts keep whispering to me that maybe the two blocks make a perfect match from the architecture point of view, and there is no need to worry about the dependency ;-)

All in all, the Enterprise Library, the CAB, the GAT - are simply amazing. Big thank you to all the contributors!

May 31, 2005 at 2:25 AM
originally posted by: headlam

Ed, if folks migrate to CAB, I think they would like to have offline capabilities as well. I general believe that the offline capability is a service that should be provide by the CAB. Like all services I have the option to opt out and use another service that provides similar or same capabilities. I would, therefore, say a dependency of the * new offline * block on the CAB is not so bad. Yes you would prefer not to have it, but if it is so bad not to have the dependency, then I have no problem having it. This is not true the other way around (i.e., the Cab should not be dependent on the offline block). I view this similar to the configuration block in EntLib. Other EntLib blocks have a dependency on configuration, but not vise-versa.
May 31, 2005 at 9:51 AM
originally posted by: AlexFed

Amen to that ;-)
Jun 28, 2005 at 8:37 AM
originally posted by: EdJez

Yes - agree on the concept, the challenge is to support users of offline that don't have a need for CAB... I posted a blog entry here about this: