ThetaDev/automerge
1
0
Fork 0
Code Issues Pull requests Projects Releases Activity
automerge/rust/automerge-c/README.md
Alex Good dd3c6d1303
Move rust workspace into ./rust 
After some discussion with PVH I realise that the repo structure in the
last reorg was very rust-centric. In an attempt to put each language on
a level footing move the rust code and project files into ./rust
2022-10-16 19:55:51 +01:00

2.5 KiB
Raw Permalink Blame History

Methods we need to support

Basic management

  1. AMcreate()
  2. AMclone(doc)
  3. AMfree(doc)
  4. AMconfig(doc, key, val) // set actor
  5. actor = get_actor(doc)

Transactions

  1. AMpendingOps(doc)
  2. AMcommit(doc, message, time)
  3. AMrollback(doc)

Write

  1. AMset{Map|List}(doc, obj, prop, value)
  2. AMinsert(doc, obj, index, value)
  3. AMpush(doc, obj, value)
  4. AMdel{Map|List}(doc, obj, prop)
  5. AMinc{Map|List}(doc, obj, prop, value)
  6. AMspliceText(doc, obj, start, num_del, text)

Read (the heads argument is optional and can be on an at variant)

  1. AMkeys(doc, obj, heads)
  2. AMlength(doc, obj, heads)
  3. AMlistRange(doc, obj, heads)
  4. AMmapRange(doc, obj, heads)
  5. AMvalues(doc, obj, heads)
  6. AMtext(doc, obj, heads)

Sync

  1. AMgenerateSyncMessage(doc, state)
  2. AMreceiveSyncMessage(doc, state, message)
  3. AMinitSyncState()

Save / Load

  1. AMload(data)
  2. AMloadIncremental(doc, data)
  3. AMsave(doc)
  4. AMsaveIncremental(doc)

Low Level Access

  1. AMapplyChanges(doc, changes)
  2. AMgetChanges(doc, deps)
  3. AMgetChangesAdded(doc1, doc2)
  4. AMgetHeads(doc)
  5. AMgetLastLocalChange(doc)
  6. AMgetMissingDeps(doc, heads)

Encode/Decode

  1. AMencodeChange(change)
  2. AMdecodeChange(change)
  3. AMencodeSyncMessage(change)
  4. AMdecodeSyncMessage(change)
  5. AMencodeSyncState(change)
  6. AMdecodeSyncState(change)

Open Question - Memory management

Most of these calls return one or more items of arbitrary length. Doing memory management in C is tricky. This is my proposed solution...

  // returns 1 or zero opids
  n = automerge_set(doc, "_root", "hello", datatype, value);
  if (n) {
    automerge_pop(doc, &obj, len);
  }

  // returns n values
  n = automerge_values(doc, "_root", "hello");
  for (i = 0; i<n ;i ++) {
    automerge_pop_value(doc, &value, &datatype, len);
  }

There would be one pop method per object type. Users allocs and frees the buffers. Multiple return values would result in multiple pops. Too small buffers would error and allow retry.

Formats

Actors - We could do (bytes,len) or a hex encoded string?.
ObjIds - We could do flat bytes of the ExId struct but lets do human readable strings for now - the struct would be faster but opque Heads - Might as well make it a flat buffer (n, hash, hash, ...) Changes - Put them all in a flat concatenated buffer Encode/Decode - to json strings?