Issue Tracker Operations

[FintanH]

Some relevant conversation happened in radicle.community.

The actions users take on the issue tracker should be translated into units of operations that will be gathered together to make up our operation-based semantics.

This will be similar to git-bug so there is opportunity to investigate and gather inspiration from that project. However, this task will also be influenced by the progress: #53.

The output of this task should be the set of operations that users can make. The semantics should be commutative to be operation-based CRDT compliant.

[FintanH]

Something I'm thinking about here is that the functions in #57 should be defunctionalised. This should allow the API to stay "pure" in its output and then the interpreters will do the side effects.

For example, an in-memory interpreter is what we have now, but another interpreter would output these ops to the datastore (e.g. commit the operation).

It's simple enough to do single operations, but I wonder if we want CPS-style, or just use some kind of state to accrue the actions 🤔 Like would it be an AST of actions we can take on threads, comments, and issues? Just spit-ballin' here. I've never used a technique like this before (or at least properly) but I feel like it's what we want.

[kim]

You mean... radicle? 😂

Not sure how well this works in Rust due to lifetime-tracking. Also, since there is no effect typing, would there be an advantage over a final encoding (ie. traits)?

[FintanH]

lol! I do love re-inventing the wheel...

So it seems like I have an initial algebra here: https://github.com/radicle-dev/radicle-link/blob/wip/issue-defunc/radicle-tracker/src/defunc.rs, which doesn't need lifetimes, just a Box.

Also, since there is no effect typing, would there be an advantage over a final encoding (ie. traits)?

The only thing I can see at the moment is that the interpreters can choose what they output. But I suppose that can be done with type Output on the trait 🤔 So unless we wanted reply().delete() to be a no-op and have "optimisations" 😅

I guess I'll take a crack at looking at a trait version and see if that makes more sense.

[FintanH]

Oh actually, something that we'll need to do is transfer over the wire what editing was done to a comment. I think this might be better represented by some enum which we can serialise.

Or would that be just as trivial with a trait, @kim?

[FintanH]

Another thought: we can assign extra metadata to the defunctionalised enums. For example, say we wanted to add an operation identity, this means we can add it for the operational interpreter but can still be ignored by the in-memory one.

[FintanH]

Instead of thinking about final vs initial algebras, I'm changing course to explore https://github.com/rust-crdt/rust-crdt. I'm going to test out Orswot, which is an "Add-Wins-Set", for Labels. Then work back from there, checking how to represent the API best.