Compound Proxies - Copies or References

Overview

Compound Proxies in ParaView3 could be stored in a session file either by-value, or by-reference. 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.

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.

Storage By-Instance?

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 in the instance grouping. When restored, the compound proxy is created along with its child proxies. This means, once a compound proxy is created it becomes its own entity. The definition is a template to create instances, but the instance does not need to remain identical to the template.

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.