Sync setup workflow

[dbr]

In playing around with the MVP version of taskchampion, I encountered these issues:

• There's the known problem of taskchampion-sync-server giving an unhelpful error when run without args (https://github.com/djmitche/taskchampion/issues/131 - solution is just to specify --data-dir)
• It was slightly confusing that there is ~/.local/share/taskchampion-sync-server/ by default - so 'task sync' works even if I don't have a server setup.. I think? (could be confusing myself)
• Unclear how to configure the sync server address
• Are multiple sync servers supported? (and encouraged?)

I'd expect roughly the following flow for a user to set up syncing:

• If I run task sync it would error saying "ERROR: no sync server configured, run [...] to configure sync-server address"
• There would be a command to easily set the remote server, e.g task sync set-url [...] or similar
• The server URL could also be edited directly into the config file

[djmitche]

#131 used to be about that weird error, which is where I discovered that kv is abandoned. I also couldn't see a quick way to match that error, as it's not clear where those types are exposed. So with a newer DB backend, we should be able to give better errors.

The implicit local sync server was a deliberate choice. A replica doesn't actually work very well if it never syncs -- its storage grows without bound, even if tasks are deleted, as it must keep a list of every operation performed on the task list since the first. The sync process allows a replica to delete operations that have been sync'd to the server, and keep only the set of existing tasks, which is of relatively constant size. The approach is specifically designed to allow an easy migration from a single replica syncing locally into a single replica syncing remotely.

You're right about the docs -- I added #156 for that.

No, multiple sync servers are not supported. In the OT model, a sync server's main job is to be the arbiter of what the "current" state is, and allow step-by-step changes to that current state. If there were multiple servers, then there would be multiple "current" states with no way to disambiguate them. It'd be like having a google doc that is also an office 365 doc.

I like the idea of editing the config with commands, and I think TOML has good support for that. Let's break that out into another issue.

How about the following flow:

• Docs encourage running task sync in a crontask, even if only for one replica
• Running task sync with no sync config gives a brief help message reinforcing the necessity of syncing and suggesting either connecting to a remote server or or configuring a local sync, with copy-pastable task sync setup <whatever> commands to do either one of those (or, if automatic config editing isn't in place yet, copy-pastable config snippets).
• Subsequent task sync works without issue.

[dbr]

That all makes sense!

I've opened an issue for the config-setting CLI option, https://github.com/djmitche/taskchampion/issues/164

How about the following flow:

Seems good! One additional step might be a reminder "warning" when sync hasn't been run for a while (e.g if user adds a task and there is x number of unsynced operations, or the last sync was more than y days ago) - would need to be done carefully to avoid being annoying of course

[djmitche]

That's a good point!

[djmitche]

I changed the discussion title to "Sync setup workflow" since this is about the client-side setup, rather than running a sync server.