DDS Migration Shim

[CraigMacomber]

Description

Proof of concept Work in Progress.

Introduce "SharedObjectKernel" and "SharedKernelFactory" abstraction as internal types to use to build SharedObjects.

These abstractions separate the DDS specific policy logic from the state and actual SharedObject instance, as well as avoid using subclassesing as an API to reduce coupling.

For compatibility with the existing runtime logic using SharedObjects, a generic SharedObjectFromKernelFull implementation is included which wraps the kernel based policies, though the API to use it is just the makeSharedObjectKind function, avoiding leaking the class even as an internal API.

SharedObjectFromKernelFull uses a proxy to graft the user facing API surface onto the same object that the runtime talks to (which provides op application and such). Ideally these would remain separate objects to avoid exposing the APIs the runtime uses to customers. If all DDSs used this implementation, modifying the runtime to provide this separation would be practical (user facing API could be behind a property on the SharedObject of the runtime facing one could be behind a symbol or map from the user facing one)

This approach is intended to be as similar as possible the migration adapter will have a single shared object that can delegate to a kernel which gets replaces when the migration occurs.

Breaking Changes

This POC currently breaks some legacy APIs and tests.

Reviewer Guidance

The review process is outlined on this wiki page.

This code is not ready for review, however feedback on the high level approach of using kernels and the use of the proxy would be helpful.

It's possible to avoid the proxy leaving several options for how to setup the APIs:

1. Manually subclass and forward all the APIs to the view/adapter for each shared object kind.
2. Generate inherited (or own) getters to put on the SharedObject's prototype which forward to each property (inherited or own) on the adapter. Possibly include a way to filter these.
3. Use a proxy (what the current code does)
4. Modify the runtime/shared object API so that the user facing object (what you get from create and handle.get can be a separate object provided by the shared object (ex: from a property). Existing SharedObjects can just return this to avoid any behavioral changes for now.

Option 4 seems like the best choice: feedback on if that is practical and how to do it would be useful.

[github-actions]

🔗 No broken links found! ✅

Your attention to detail is admirable.

linkcheck output

> [email protected] ci:check-links /home/runner/work/FluidFramework/FluidFramework/docs
> start-server-and-test "npm run serve -- --no-open" 3000 check-links

1: starting server using command "npm run serve -- --no-open"
and when url "[ 'http://127.0.0.1:3000' ]" is responding with HTTP status code 200
running tests using command "npm run check-links"


> [email protected] serve
> docusaurus serve --no-open

[SUCCESS] Serving "build" directory at: http://localhost:3000/

> [email protected] check-links
> linkcheck http://localhost:3000 --skip-file skipped-urls.txt

Crawling...

Stats:
  160781 links
    1452 destination URLs
    1683 URLs ignored
       0 warnings
       0 errors