Create a project managment layer in thimble using makedrive

[JordanTheriault]

Makedrive will allow us to do block-level synchronization for user data.

[gideonthomas]

Few changes need to happen to makedrive here (there could be more which we will find out after we switch to using it):

• The auth stuff needs to be changed so that we can use the new ID system
• We need to be add logic to disable redis locks on syncing
• https://github.com/mozilla/makedrive/pull/458 needs to be landed so that other problems that were already existing with makedrive (e.g. broken compatibility with Filer) are fixed

We need to also figure out a way to communicate fs changes between thimble and brackets. I think @sedge's idea of using postMessage to send changes from brackets to thimble and then have thimble commit the changes seems to be a common approach for solving CORS re: indexeddb. We might not even need to have two file system instances (one for brackets and one for thimble). We might just use the current FilerFileSystem to act as a proxy and send commands via postMessage to thimble (which will process the fs command) and send back the result.

cc @humphd

[sedge]

We need this layer to use makedrive to pull down the project that a user selects, to manage which projects are open (so a project can't be opened more than once at a time) and to communicate changes to and from brackets.

[gideonthomas]

I don't think makedrive (at least on the client side) should manage which projects are open. One approach that we could use is to restrict how we display the list of a user's projects to the user when they open up thimble. As per our current conceptual design, when a user opens up thimble (logged in), the user sees a list of their projects (and maybe other's published projects) which is done by querying the server. If we decorate the data that the server returns back well, we can indicate which projects are open based on the status of open websocket connections for that user and their corresponding sync roots.

tldr; when a user opens up thimble, the server can tell the client which projects are currently open and we can maybe disable them from the choices the user has re: projects to open

[sedge]

Makedrive wouldn't be managing the projects, that's for sure.

Thimble needs logic to determine what to allow a user to open. I like your idea of including a flag in the GET /user data for which projects are already active in a bramble instance, but thimble still needs to know how to handle that.

[gideonthomas]

I think we also need (for IE compatibility) to prefer using MessageChannel if it is supported (Firefox does not support it by default), and fallback on PostMessage otherwise.

[gideonthomas]

^ this is mainly because IE does not support Transferable objects so passing ArrayBuffer's across postMessage will be a pain (continuous serialization and deserialization cycles)

[gideonthomas]

Here's out current plan btw https://etherpad.mozilla.org/thimble-plublish-plan

[sedge]

This issue shouldn't live here. See: mozilla/thimble.webmaker.org#531