Hi @AlanOoi
This is a great start. Thanks for putting this into an RFC!
The “scoping of content” piece should also include real-world cases where different models are used on DC vs Cloud. The RFC assumes a 1:1 mapping between DC/Cloud macros, custom content and content properties, but this is not necessarily the case. For example, a DC app might store metadata about content objects in its own ActiveObjects table. On cloud, this could be transformed to store data in-app and thus be represented as a content property associated with specific content.
Possibilities for solving this problem might include:
- asking the apps themselves to declare (via CCMA) the content IDs and other objects that they need to be able to manipulate on Cloud, or
- just allow apps to access all content in the space during the migration window. I understand the intent behind the minimization of scope, but apps can access 100% of this pre-migrated data anyway on DC, so maybe this is less of a concern? This behaviour could be mitigated somewhat by only providing this scope of access for API calls that include the migration header, so as to prevent regular app code path from triggering this extended access.
Apps may also need to write to arbitrary space properties, despite there not necessarily being a 1:1 map on the DC side.