gothenburgbitfactory / taskchampion Goto Github PK

Right now, it's task add <description>.

A quick walkthrough of adding a task, listing, starting, finishing, modifying, syncing.

Instead of always requiring a uuid, allow small numbers, similar to how taskwarrior does it.

I think this is already partially implemented with the "working set" concept.

..and task states at the same time

Currently the cli config assumes a remote server. That was an oversight. By default, it should use a local sync.

Fix its initial warnings, then add it to CI.

I spent some time working on a TDB2 implementation and trying to port the TW command-line parser (uncovering some fun bugs in the process). I don't think we should keep that! I'll move it to a branch and put that in a closed PR, just to keep a pointer to it.

Once there's an MVP for this project, we'll want to get people in to start using it and start hacking on it. That means talking about it in public.

• Blog post highlighting it
• Posts on Reddit?
• Posts on Twitter?
• Posts on Hackernews?
• Posts on .. whatever?

I can do the blog post, but I'm not a big participant in the social corners of software engineering, and I'm not on any of the social apps listed above. So I will need some help here!

Something that exposes an HTTP API against which task sync can run

Hawk is a holder-of-key authorization system that signs requests. Canonical implementation is https://github.com/mozilla/hawk and there is a rust implementation as well.

Disclaimer: I didn't write Hawk, but as a major user of the protocol at work have kind of inherited its maintenance. It's well-suited to this purpose and I'm pretty familiar with it, so I think it's a good choice here.

Another alternative would be API keys, but as those don't sign requests or payloads I consider them a little less reliable.

I might be interested to join

Sync can potentially change the set of pending tasks, so it should update the working set. It's also the point where we know the replica's data is backed up, so it seems like a good time for garbage collection.

In most cases, we want to either list tasks annotated with their working set ID, or get a single task by its working set ID. Let's refactor a bit.

At least, let's use usize for indexes.

As described in the development docs: server requests a snapshot from the client, client produces one

Progress

• server side
  • #289
  • #294
  • #295
  • garbage collection (deleting versions)
• client side
  • #300
  • #305
• include all of this in integration tests
  • #310

These should stop the task and change its status. Depends on #7.

While I'm at it, I'll remove the delete_task method from Replica -- deletion should be handled through the as-yet un-implemented expiration process.

• Written process for making a release, what to upload to GH, what to Crates.io, etc.
• Push book to a github pages account
• Distribute the version number from top-level Cargo.toml to each crate using build.rs

The sync server only uses taskchampion::Uuid, which is a re-export.

• Development Guide
• PR template
• Issue templates

task list and task pending both show tasks in a Rust debug format. Let's do something approximating TaskWarrior.

The TaskWarrior CLI is pretty expressive, in a non-traditional way:

# multi-word inputs:
task add this is my new task
# some commands take a task prefix, that can be either an id or a partial uuid
task 1 info
task b41508f5-e713-478f-927d-110715d65947 info
task b41508f5 info
# tags have a + prefix, and can either filter or specify
task +next list
task 1 modify +next

The clap library is not built for that sort of thing. It's also not terribly friendly about distributing the syntax for subcommands over lots of modules.

Let's build a better solution that uses an actual parsing library that can express the similarities and differences between subcommands without too much redundancy.

Basically, enough to put in a README so that someone can try this out -- no more.

• a simple tool to add a client to the server (maybe just curl)
• a way to configure the client for task sync without going to the lengths of a config file

• db / operation model is just k/v, but formatted names can be used for
  structure:
  • dependencies: dependency.<uuid> = ""
  • annotations: annotation.<epoch time> = "annotation"
  • tags: tags.<tag> = ""

add /add-version and /get-child-version endpoints that verify signatures and call the backend defined in #55.

TaskWarrior has a bunch of synthetic tags like +WAITING and +PENDING. We could do the same thing pretty easily. They should be synthesized entirely within the replica, rather than stored in the task DB.

This will be a peer to LocalServer that interfaces with the remote web server defined in #56.

This might be a good time to add taskchampion::sync that can handle the intermediate signing bits instead of putting those in TaskDB.

In this design, the server is little more than an authenticated storage for encrypted blobs provided by the client. To allow for failure or data loss on the server, clients are expected to cache these blobs locally for a short time (a week), along with a server-provided HMAC signature. When data loss is detected -- such as when a client expects the server to have a version N or higher, and the server only has N-1, the client can send those blobs to the server. The server can validate the HMAC and, if successful, add the blobs to its datastore.

(updated to include the proposal directly, instead of via a link)

Similar syntax to TaskWarrior for adding, removing, and filtering by tags.

The sync model is such that there's a point in the list of operations that is committed. That can be used to determine when to delete an expired task -- basically, when an op after its expiration time has been committed.

That might need to be recorded as an operation? Needs a bit more thought.

Using the usual rust logging tools..

(from #11)

Sort of like git will find a .git directory by going upward toward the fs root, let's look for .taskchampion.yml files up the directory hierarchy, and apply them in reverse order.

This will let folks apply defaults to specific subdirectories, e.g., if I'm in ~/my-novel then the default report might just show tasks tagged with +novel.

This should be similar to taskchampion::taskstorage, but specialized to store the data expected of a server as described in #34.

Aside from various management methods, this should have an add_version method that satisfies the necessary atomicity guarantees.

The intent is that the server should be able to store data in a variety of backends.

Something like

• taskchampion-replica -- task storage, taskdb, and client-side sync mechanics
• taskchampion-sync-server -- the sync server
• taskchampion-cli -- the command-line tool

Let's use an existing format, maybe TOML?

This will help ensure uniqueness!

One point here is that a lot of operations depend on sync, especially expiration. So we'll need to find a way to make a standalone instance "sync" with itself anyway. That might also serve as a good, if local, backup. This is something to think about in the design, but not necessarily implement just yet.

Run cargo test etc.

Reasons mentioned in #4. This should come with a revision of the README, too.

..using https://github.com/rust-lang/mdBook

..defaulting to it when given a task number or uuid.

It should show all fields of the task, not just those in the columnar report.

There's a lot of unwrap() and panic! going on, emulating the unsafe bits of the Taskwarrior code. Let's do that the right way.

The first pass on a client-server protocol can just use cleartext, but the real thing should use encryption on the client side, so that the data is not readable on the server.

and also include states != completed, deleted

Exporting this type will allow consumers to use it without finding exactly the same version of the uuid crate.

The server currently only has an inmemory implementation. Add one that uses kv, similar to taskchampion::taskstorage.

The Task structure should not have any reference to serialization formats. Move the depends parsing, etc. into the tdb2 module.

Add this to TaskStorage and to TaskDB.

Currently, Replica must fetch the full working set on every operation. At least some storage backends can probably do better.