Compound Proxies - Copies or References

From ParaQ Wiki
Revision as of 12:33, 6 July 2006 by Tshead (talk | contribs) (→‎Combined Proxy / Child Storage)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Overview

Compound Proxies in ParaView3 could be stored in a session file in several different ways. This document describes pros-and-cons of each approach:

Storage By-Value

When the user creates an instance of a compound proxy (by clicking on its toolbar icon, for example), the server instantiates all of its child proxies and connections. When the session is saved, all of these child proxies are saved, like any other proxies. When the session is reloaded, these child proxies are loaded, like any other proxies. The fact that they are part of a compound proxy is essentially ignored.

Pros

  • Simplicity - Adding a compound proxy to a session is making a copy of its child proxies. Once instantiated, those proxies require no further special treatment, simplifying the code.
  • Stable behavior - When a user loads a saved session, the session will behave the same as it did when saved, regardless of any intervening changes to compound-proxy definitions.
  • Easy collaboration - A saved session can be distributed and will produce identical results for all users, whether they have the same compound proxy files as the originator or not.

Cons

  • Restoring the child proxies will look different to the user. The pipeline browser would show a compound proxy before saving. When restored, the compound proxy would be replaced by the sub-proxies.
  • The exposed properties concept is lost.

Storage By-Reference

When the user create an instance of a compound proxy, the server instantiates all of its child proxies and connections. When the session is saved, the child proxies are ignored, and in their place a reference to the file that contains the compound proxy is saved. When the session is reloaded, the compound proxy file is loaded, and the child proxies are re-created from its contents.

Pros

  • Easy upgrades - Modifications to a compound proxy are automatically propagated to existing sessions when they are reloaded.

Cons

  • Unwanted upgrades - Modifications to a compound proxy may have unwanted side effects on existing sessions.
  • Collaboration complexity - It would no-longer be enough to share a session file with a colleague, the entire collection of referenced compound proxy files must be shared & installed, too.

Combined Proxy / Child Storage

When the user creates an instance of a compound proxy, the server instantiates all of its child proxies and connections. When the session is saved, the child proxies are saved, along with compound proxy membership information. When restored, the compound proxy is created along with its child proxies. This implies that once a compound proxy is created it becomes its own entity. Although the child proxies continue to be identified as "members" of the compound proxy, they can be individually added / deleted / modified. Thus, the original compound proxy is a "template" for creating instances, but those instances do not have to remain identical to the original.

Pros

  • The exposed properties concept can still be used.
  • The user will still see a compound proxy when the session is restored.
  • The compound proxy instance and template do not have to be consolidated.
  • The restored state will work regardless of any compound proxy definition changes.

Cons

  • Will the users get confused by the template idea?
  • New compound proxy definitions would not automatically get propagated to the instances. Some method would have to be designed to allow a state file to be upgraded. This could be a benefit to avoid unwanted upgrades.

Embedded Proxy

When the user creates an instance of a compound proxy, the server instantiates all of its child proxies and connections. When the session is saved, a copy of the original compound proxy is embedded in the session, and all instances of the proxy reference it (internally). When the session is restored, child proxies can be instantiated from the embedded copy of the compound proxy, or from an external version.

Pros

  • Combines the best of by-value and by-reference storage. The user can be prompted at session load time to either: upgrade compound proxies that have changed, or use the embedded version to ensure that behavior remains identical to what was saved.
  • Sessions can be shared electronically as a single file.

Cons