Closed jessegrosjean closed 6 months ago
Same question about repo.clone()
? It also seems to be a new api/terminology that isn't super necessary. And the underlying implementation uses doc.fork()
which is a detail that seems like it might be of interest to clients. In my mind it might make more sense to:
repo.create(doc: docHandle.doc.fork())
repo.fork(id: id)
so that API is reusing existing automerge terminology to describe more exactly what is happening.Of course these are just outsider thoughts/suggestions without me knowing to much. Close and ignore as needed :)
Thanks @jessegrosjean - super useful insight as usual!
I replicated the top-level functions (without change or really, any thought) from the Javascript automerge-repo. The import, export, and clone also seemed somewhat repetitive to me, being used to working with getting data in and out of an Automerge doc directly doc.save(), doc.fork(), etc.
In the JS side of the world, this is also more of a server component, and in particular there's some interesting wrangling of mixing together full syncs and "local changes" and persisting those separately (and later recombining them) that's embedded in the concept of the storage adapter - and I suspect that may have impacted the concept of the import and export - those are always as compacted documents, where the storage adapter works quite differently (but does support concurrent updates of multiple peers to a single filesystem location)
The notable factor of clone is that it makes a new document ID alongside the forked document, in essence doing exactly the same thing you're outlining in repo.create(doc: docHandle.doc.fork()) - so yeah, definitely repetitive with that concept.
I'm reading through high level docs and seeing import/export API made me think there was some new concept I need to learn.
In my mind:
repo.create(data: data)
docHandle.doc.save()