MaterialsImplDiscussion - Revision history

Justincc: /* Cons */

2014-07-04T19:49:40Z

‎Cons

2014-07-04T19:49:23Z

‎Cons

2014-07-04T19:47:55Z

‎Cons

2014-07-04T19:47:44Z

‎Cons

2014-07-04T19:46:41Z

‎Store materials data as temporary assets until persistence definitely required

2014-07-04T19:32:31Z

‎Approaches

2014-07-04T19:30:19Z

‎Cons

2014-07-04T19:29:57Z

‎Store materials data as temporary assets until persistence definitely required

2014-07-04T19:28:01Z

‎Store materials data in a prim's dynamic attributes

2014-07-04T19:27:36Z

‎Store materials data in a prim's dynamic attributes

@@ Line 58: / Line 58: @@
 === Cons ===
 * Persistence triggers need to be hooked by the module.  In time critical cases (e.g. region crossing) one would have to be very careful not to unnecessarily delay other code.  The module needs to be careful not to generate corrupt or inconsistent data if there is a simultaneous change to the material at the time of persistence.
-* Cache needs to be managed (chiefly removal of items when no longer required).
+* Cache needs to be managed (chiefly removal of items from memory when no longer required).
 === Pros ===
 * Materials can be rapidly changed without [de]serialization or asset storage overhead.

@@ Line 48: / Line 48: @@
 === Cons ===
 * Persistence triggers need to be hooked by the module.  In time critical cases (e.g. region crossing) one would have to be very careful not to unnecessarily delay other code.  The module needs to be careful not to generate corrupt or inconsistent data if there is a simultaneous change to the material at the time of persistence.
-* Temporary assets don't need to be managed but have the potential to flood the simulator's disk asset cache.
+* Temporary assets have the potential to flood the simulator's disk asset cache.  This needs to be prevented (which may be a general requirement to improve the simulator cache) and managed (to remove temporary assets when no longer needed).
 === Pros ===

@@ Line 57: / Line 57: @@
 === Cons ===
-* Persistence triggers need to be hooked by the module.  In time critical cases (e.g. region crossing) one would have to be very careful not to unnecessarily delay other code.n.
+* Persistence triggers need to be hooked by the module.  In time critical cases (e.g. region crossing) one would have to be very careful not to unnecessarily delay other code.  The module needs to be careful not to generate corrupt or inconsistent data if there is a simultaneous change to the material at the time of persistence.
 * Cache needs to be managed (chiefly removal of items when no longer required).
 === Pros ===
 * Materials can be rapidly changed without [de]serialization or asset storage overhead.

@@ Line 47: / Line 47: @@
 === Cons ===
-* Persistence triggers need to be hooked by the module.  In time critical cases (e.g. region crossing) one would have to be very careful not to unnecessarily delay other code.
+* Persistence triggers need to be hooked by the module.  In time critical cases (e.g. region crossing) one would have to be very careful not to unnecessarily delay other code.  The module needs to be careful not to generate corrupt or inconsistent data if there is a simultaneous change to the material at the time of persistence.
 * Temporary assets don't need to be managed but have the potential to flood the simulator's disk asset cache.

@@ Line 49: / Line 49: @@
 * Persistence triggers need to be hooked by the module.  In time critical cases (e.g. region crossing) one would have to be very careful not to unnecessarily delay other code.
 * Temporary assets don't need to be managed but have the potential to flood the simulator's disk asset cache.
 === Pros ===

@@ Line 23: / Line 23: @@
 = Approaches =
 ==Store materials data in a prim's dynamic attributes==
 Materials are stored in the prim's [[Feature_Proposals/Dynamic_Attributes_in_Scene_Objects|dynamic attributes]] whenever changed.

@@ Line 27: / Line 27: @@
 === Pros ===
-* All mechanisms required to
+* All mechanisms required to persist dynamic attributes to both serialization and region database are already implemented and active.
 ==Store materials data as temporary assets until persistence definitely required==