My goal is to try to make PM work with a nosql db and no server side (ie Firebase etc). I think this can be in general a very useful application. The problem is the nature of such a db is that transactions operate on a single key, so adding multiple steps in a single transactions is problematic. I will need to do a transaction on the parent - the one holding all steps and that is extremely inefficient as it means sending all versions back to the client.
(see Firebase transaction doc)
So instead of that I simply store the result of sendableSteps which has version as key and a dictionary of zero based index:step as value. I then listen for new children starting at root\version == getVersion. This works, but the down side is that the versions on the db are not sequential: version 0 with steps 0-4 then version 5 with steps 0-2 etc which is ugly and means I have to ‘flatten’ the server response to an array of steps on the client.
The bigger problem is with merging steps as explained above. Basically the underlying issue is that collab assumes a flat steps structure so that version is the step index which is not the way I want it in my case.
Another problem is that implementing snapshots get tricky, as I need to store what step index does the snapshot version corresponds to.
(as a side note there is a slight advantage to this structure, I can store clientID only once per version instead of with every step).
What I need is a way to manage collab versions myself. Basically I am asking for a reset(state, version) method in collab that will reset the plugin with an editor state and a version and an empty local ‘history’ (empty steps array). or even better, for receiveTransaction to accept an optional version argument and reset the internal version to that argument. This will allow me to do the version bookkeeping myself and solve the above issues in a clean way.
Another approach, IMO the best but require an API change, is to remove version handling from collab altogether. That is remove getVersion and remove version from plugin initialization and the return of sendableSteps. To achieve the current behavior, the client will simply hold it’s own version variable and do version+=steps.length after calling receiveTransaction and use that version instead of the one returned from sendableSteps when needed.
Any thoughts ?