| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This allows region modules to add dynamic objects to SOPs rather than having to continually push and pull OSD dynamic attributes.
This is to explore the original MOAP use case for dynamic attributes where it could be very awkward and possibly time-consuming to keep reconstructing MediaEntrys from stored DynamicAttributes.
This commit adds a DOExampleModule to demonstrate/evolve this code.
Dynamic objects involve no storage or persistence changes - the 'backing store' for any data that does need to be saved will remain the DAMap.
DOExampleModule in this commit only attaches a fresh dynamic object. Actually constructing this from stored dynamic attributes and handling persistence is left for later.
These changes should affect no existing functionality, though it may or may not reveal necessary changes in DAMap down the road.
|
|\ |
|
| | |
|
| |
| |
| |
| | |
match Add(string key, OSDMap store)
|
|/
|
|
|
|
|
|
|
|
|
| |
script functions. Adds JsonAttachObjectStore to associate a store identifier with
an object (scripts can only access the store in their host object, this could be
extended but isn't necessary for now).
Note this opens a method to the DAMap OSDMap. This will be removed later, but
greatly simplifies the code for now.
The JsonStore and these scripts are disabled by default.
|
|
|
|
| |
use deep copy for DynAttrs.
|
|
|
|
| |
names must have at least 4 characters.
|
|
|
|
| |
This allows external lockers to preserve atomicity of dynamic attribute changes
|
|
from it
This is the easier way to give us control over locking, rather than asking that OSDMap IDictionary methods be virtual
|