| 28 | | * Resources from unknown AMs: |
| 29 | | * An IG manifest may includes components whose component_manager is not in the Jacks context, and for which the Portal will never send a manifest. |
| 30 | | * The result is Jacks shows resources that cannot be manipulated through the portal |
| 31 | | * Action: Jacks should only show nodes in View mode whose component_manager matches one of the aggregates in the current Jacks context |
| | 28 | * Resources from other AMs / merging manifests: |
| | 29 | * An IG manifest may includes components which are not from the current AM |
| | 30 | * They may even be from AMs not known to the portal |
| | 31 | * The result is |
| | 32 | * The resources listed in that manifest may have since been deleted at the "real" AM, but Jacks still shows them |
| | 33 | * If the resources exist but at an AM not in the Jacks Context and not known to the portal, then Jacks shows resources that cannot be manipulated through the portal |
| | 34 | * Action: |
| | 35 | * Option 1: Jacks should only show nodes in View mode whose component_manager matches one of the aggregates in the current Jacks context |
| | 36 | * Option 2: When in view mode and receive an RSpec of type 'manifest', only show nodes from the sender aggregate (alternatively implement as only nodes with a sliver_id) |
| | 37 | * Links between AMs will need to be drawn like shared VLANs, with dangling endpoints |
