Compound Proxies - Copies or References: Difference between revisions
No edit summary |
(→Cons) |
||
Line 14: | Line 14: | ||
==== Cons ==== | ==== 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. | |||
=== Storage By-Reference === | === Storage By-Reference === |
Revision as of 12:59, 23 June 2006
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.
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.