v1

[sungwoncho]

dnote server as the source of truth

Problem: It is impractical to maintain local copy of notes and the server copy at the same time. Doing so, we have to reinvent git. The reason is that dnote needs to resolve conflicts between web and cli. Also users need to pull new data from the server.

Solution: dnote writes to a local copy that gets flushed to the server on every nth command execution.

Shortcomings:

1. Users no longer automatically have all their data on their disk.
2. Users cannot use dnote offline out-of-box.

Benefits:

1. Users can still download backup of their data using dnote backup. (solution to shortcoming 1 and 2) -- see below
2. Multi machine support is possible. This is a frequently requested feature, and will help people using dnote between work and home machine.
3. Keep it simple for users, not reinventing git.

---

solution to shortcoming 2:

Allow users to browse notes and books by using a flag to specify backup file.

dnote ls javascript --backup-file-path ~/.dnote/dnote.bak

Instead of hitting the API, dnote will read from the backup file.

[sungwoncho]

@michielboekhoff what do you think?

[michielboekhoff]

@sungwoncho - this is not a bad attempt. One question about this approach: if a backup is made, and if the computer is offline, can new entries still be made in the backup file? If so, we'll have to do some form of synchronization still.

We'll have to provide some form of graceful fallback - e.g. if no network connection is detected, to automatically read from the backup file. Otherwise, this sort of online-first functionality risks making life more difficult (and backwards-incompatible) for users without a (stable) network connection.

I don't quite see the problem having local changes and then uploading these to the mainline (server). If multiple machines have changes from mainline, the server can insert these into a tree as per their creation time. Mind you, that is with immutable entries. Mutable entries would make it more difficult (e.g. Git merge conflicts).

[sungwoncho]

Thanks for your idea. I thought about it and agree that making dnote online-first is too much.

the server can insert these into a tree as per their creation time

Sounds like a good plan. How do you feel about the following for dnote sync?

1. compress local copy
2. POST to server
3. server decompresses payload
4. compare and get new entries and entries that client is missing
5. write new entries to db
6. send missing entries to client
7. client inserts payload from 6 to local copy

But the entries might be mutable in the future (editing through web client, api, etc.). My solution is when pulling from the server, we treat the server's data as source of truth and overwrite any conflicts. But I think this requires diffing all the notes while syncing and might be too slow. Any ideas welcome.

@YiiKuoChong

[sungwoncho]

@YiiKuoChong yes, the content of .dnote file is like the following:

{
  ...
  "linux": [

    {
      "UID": "4ac4h6h5",
      "Content": "$0 is the name of the running process",
      "AddedOn": 1506231335
    }
  ],
  "react": [
    {
      "UID": "94i3zquv",
      "Content": "React Element is an object representation of a DOM node",
      "AddedOn": 1499835562
    },
    {
      "UID": "c24bbcd6",
      "Content": "React Component is a function or a class which accepts input and returns React Element",
      "AddedOn": 1499835860
    }
  ]
}

[sungwoncho]

@michielboekhoff @YiiKuoChong thanks for the input. I solved the problem in #51.

In short, every time a note or a book is mutated, an action is recorded locally. dnote sync will push those actions to the server. Server will process those actions, respond with actions that have not been synced with the client yet. And the cli will process those actions to bring the local copy up-to-date with the server copy.

Sync is much efficient this way because we don't POST the entire note and loop through it on the server.

Preview is available on an alpha release. If you have feedback or questions let me know.