1. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 Update Policy ~ Where we are in 3.2

2. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 2 Agenda  Overview of Design  Design of a Prototype  What you can do in 3.2  Challenges / Issues  Plans for Next Release

3. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 3 Overview of Design  Update Policy has been split off into two components:  Update Policy  Model Proxy  Update Policy  Tightly coupled with the viewer  Created once when the viewer is created  Model Proxy  Platform provides default adapter for model proxies: E.g. variables view model proxy, expression view model proxy  Clients can create model proxy by providing adapter to IModelProxyFactoryAdapter  Install when an element with a new model proxy is mapped to a view

4. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 4 Update Policy + Model Proxy ViewerModel Presentation Context Model Proxy Element Update Policy fires deltas update Model Proxy Factory installs

5. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 5 Building an Manual Update Policy  Goal:  Build an update policy that allow user to freeze a view and update manually.  Step 1:  How should this be implemented? Option A: Change update policy in the viewer when user decides to freeze the view. Option B: Model Proxy to stop firing events when the view is frozen. Result: Option B. −There is really no API to do Option A.

6. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 6 Step 2: Design of the Prototype Create action in Variables View to disconnect the view from model. When a view is disconnected, the view will stop updating. Create action in Variables View to refresh view manually. The view will be refreshed even if it is disconnected. Set up preference for connecting and disconnecting views. Demo

7. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 7 Step 2: Design of the Prototype Customized Model Proxy Viewer Presentation Context Element Update Policy fires deltas update Model Proxy Factory installs Model Preference Store modify Disconnect Action Get Preference [Disconnect?] Debug Events

8. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 8 Step 3: When View and Model are Out-of-Sync  Problem: View and Model cannot be updated independently  View always gets the latest and greatest when: Update policy receives a model changed event Input is changed in the view (due to changes in debug context)  Caused the view to be updated even when it should not be updating.  Content needs to be cached in order to allow views and models to update independently.  Get current data after the model is changed  Return cached data otherwise  Benefits:  Performance  Allow view and model to update independently  Also allows views that show the same data to update independently. E.g Multiple Variables View, Renderings in Memory View

9. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 9 Background: Content Adapter  Content Adapter defined by type.  Shared among views.  E.g. Variables and Registers View share stackframe content adapter Viewer Model Presentation Context Content Adapter Element 1. #getAdapter Viewer Element 2. Get Children 3. Return Children

10. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 10 Step 4: Caching by Model View Cache [view id] [debug context] View Cache [view id] [debug context] Model 2. Get Children View Cache Manager [Debug Target] Content Adapter 1. Get Cache 3. Cache Data & Mark Updated Create and Manage 1.The content adapter is asked to get children. 2.The content adapter asks for cache based on presentation context and debug context. 3.If cache is empty, the content adapter gets children from its model. 4.The content adapter makes a copy of the data and store it in the cache. 5.Content adapter marks view cache as updated.

11. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 11 Step 5: View Update with Cache View Cache [view id] [debug context] View Cache [view id] [debug context] Model View Cache Manager [Debug Target] Content Adapter 1. Get Cache 2. Check #isStale() 3b. Get Children 1.Model Proxy fires a change event. 2.Viewer’s update policy receives the change event and asks the viewer to update. 3.The viewer asks the content adapter for children again. 4.The content adapter retrieves the correct cache from View Cache Manager. 5.The content adapter checks if the cache is stale. 6.If the cache is stale, the content adapter gets updated children from its model 7.If cache is not stale, the content adapter asks the cache for children and return those children. 3a. Get Children Get Cache

12. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 12 Step 6: Cache Update View Cache [view id] [debug context] View Cache [view id] [debug context] Model View Cache Manager [Debug Target] 2. Mark Stale 1.Debug session is resumed. 2.Model tells the cache manager that the cache has become stale. 3.View Cache Manager goes through its view caches and mark them all as stale. 4.Cache is updated when the same data is required again. 1. Model Resume 2. Mark Stale

13. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 13 Step 7: … when view is disconnected View Cache [view id] [debug context] View Cache [view id] [debug context] Model 4b. Get Children View Cache Manager [Debug Target] Content Adapter 3. Get Disconnect Preference 2. #isStale() 4a. getChildren Get Cache 1.Content adapter may still be asked to get children (input changed, after resume.) 2.Content adapter gets the correct cache and checks if cache is stale. 3.Content Adapter also checks the disconnect preference and see if the view is disconnected. 4.If view is disconnected, content adapter returns children from cache if it is stale. 5.Otherwise, content adapter gets current data from model. Preference Store 1. Get Cache Viewer 5. Return Children

14. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 14 What you can do in 3.2  Model Proxies allow clients to control how and when debug events are to be handled.  To implement update policies: 1.Client must define model-specific preference and actions for switching between update policies. 2.Clients must implement customized model proxies to fire and filter events accordingly. 3.Clients must implement customized content adapter to cache data and clear cache as necessary.  What we have in 3.2 is a start to allow clients have more control over view updates. We have still have many unanswered questions.

15. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 15 Challenges and Issues  Update Policy is too tightly coupled with a viewer.  Cannot be easily overridden  Should clients be allowed to contribute update policies in views? (i.e. replace the update policy in the viewer.)  Update Policy is installed in a view and shared among models. It may not be such a good idea to allow a model to swap out a view’s update policy. Need a way to restore original update policy when a model is disposed.  No clear definition of responsibilities between update policies and model proxies.  When implementing an update policy, it is unclear where it should be implemented.  This implementation of model policy is model-specific.  Unable to create generic update policies to be shared and reused.

16. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 16 Challenges and Issues  Expansion & Scrolling  Virtual Tree Viewer  Potentially cause the view to show a mix of stale and updated data. Example: View Frozen -> Step -> Expand a node  Prototype stops asking for children if content cache is not up-to-date.  Ability to disable actions in views  E.g. Logical Structure, show type names, modifying values  May not be able to support these features when data is stale  Need to be able to disable these features when needed  View population is asynchronous  Difficulties when implementing a timer update policy: Unable to tell when a view has finished updating and that the model is ready to be resumed. When there is more than one view updating, how can a model tell when all views have finished updating before it can resume.

17. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 17 Challenges and Issues  Show Changes in View  Model is responsible to mark changes (IVariable#hasValueChanged) - except for Memory View.  OK if there is only view showing the variables.  Model gets polluted when there are multiple views showing the same data. Models cannot reliably determine changes for a view.  Multiple Views on showing the same thing while on different update policy  Need to show that views are on different update policies  Need strategy for caching to ensure that views update independently  E.g. Memory View, Multiple Variables View  How to show that data is stale?  Idea: Set view to a different font before view update. When the view has finished updating, set it back to its original font.

18. Copyright (c) 2006 IBM Corporation; made available under the EPL v1.0 18 … Next Release  Workgroup to tackle some of the issues with update policies.  Define use cases and update policies.  Outline how some of the update policies would be implemented. Clarify responsibilities of update policy and model proxy.  Tackle the problems outlined on previous slides.