This makes the macro usable with public structs. #22

Probably it would be better to make the generated transform public only when the struct is public? I don't know how to cleanly put a conditional pub into the metaprogramming. I will learn how to if you agree that that is how it should be.

I'm currently trying to run the drop-four example but its not working.

I ran the following command

cargo build

It built successfully then I ran

cargo run -p drop-four-client

This return an error:

error: a bin target must be available for `cargo run`

I'm currently stuck and I would really love to try out the examples.

error[E0446]: private type `CharacterTransform` in public interface
 --> state/src/character.rs:4:10
  |
4 | #[derive(StateMachine, Clone, Debug, Serialize, Deserialize, PartialEq)]
  |          ^^^^^^^^^^^^
  |          |
  |          can't leak private type
  |          `CharacterTransform` declared as private
  |
  = note: this error originates in the derive macro `StateMachine` (in Nightly builds, run with -Z macro-backtrace for more info)

Serialize List as (ZenoIndex, Uuid, T)-tuple instead of serializing each map. This reduces its size and gets rid of the problem that Lists couldn't be serialized into JSON.

The lower-level axtix implementation allows a concept of “channels” each with independent state, but the ServerBuilder does not expose a way to do this. There should be an easy way to allow channel creation from the server.

Aper's data structures attempt to handle conflicts appropriately, but there are cases where that isn't possible. For example:

• Alice modifies a list item after Bob has deleted it.
• Alice and Bob both modify an atomic at the same time.
• Alice makes a move in a game that is now invalid because of a move Bob made.

In these cases, an object representing the conflict should be raised. This would probably be an associated type of StateMachine with a reasonable default (maybe ()).

Design questions:

• Should this be a Rust Error? In this case we could use Result<(), Conflict> as a signature for apply
• Should apply guarantee that the state has not been modified if a conflict arises, or should it be the responsibility of the state manager to roll back if a conflict comes up?
  • The latter would simplify the implementation of transactions (#7) because apply could simply raise the first conflict that arose resulting in a rollback of the entire transaction.

For built-in data structures, it might sometimes be useful to be able to atomically perform multiple operations. I'd need to give some thought to the best way to do this, but one idea is to have a Transactioned pseudo-data structure that wraps a state machine and accepts a Transaction update. Something like (not tested):

pub struct Transaction<T: Transition>(Vec<T>);

pub struct Transactioned<T: StateMachine>(T);

impl<T: StateMachine> StateMachine for Transactioned<T> {
    type Transition = Transactioned<<T as StateMachine>::Transition>;

    fn apply(&mut self, transition: Self::Transition) {
        for t in transition.0 {
            self.0.apply(t);
        }
    }
}

There are a number of ways to refer to a position in a List, which determines the behavior when the list has changed between when the reference is created and when it is used:

• At the beginning/end of the list
• Between two adjacent items
  • Two types of anchor behavior: anchor to the first, anchor to the second (only matters if one is moved or something is inserted between them)
  • A possible third: anchor to whichever has not been moved
• Immediately after an item
• Immediately before an item
• At a specific fractional index

When adding an item in reference to another item, we usually want to fall back on a fractional index. That way, if the item it is in reference to is removed, we can fall back on the index.

For simplicity the right approach here is probably something like:

pub enum ListPosition {
    Beginning,
    End,
    AbsolutePosition(ZenoIndex),
    Before(Uuid, ZenoIndex),
    After(Uuid, ZenoIndex),
}

This would accomplish the most common use cases, but not the more complex ones.

Currently, the client waits to receive a transition back from the server, even if it is waiting for a transition that originated on that client. This is necessary because applying that transition immediately risks a case where another user has issued a conflicting transition at the same time that arrives at the server first, which would cause the local state to be inconsistent.

To get around this, we can keep two copies of the local state: one with only transitions from the server applied to it, and one with local transitions as well. We use the one with local transitions to display the state, but if we ever receive an unexpected transition from the server, we roll back to the local server version.

It would make it easier to explain/teach the principles behind Aper if I had a demonstration environment that could run locally in the browser. It would be implemented in the form of a Yew component. It would render two (or more?) copies of a component, with state synchronized between them. Messages between them would appear in the UI.

In order to allow something like a Kanban board, we would want to have multiple data structures that items could be moved between. The best way to accomplish this would be to allow multiple lists to share a pool of objects.

In order to avoid a state where multiple data structures contain the same item, we would also need a way to make multiple state updates atomic (e.g. #7).

Aper should have a Tree data structure that would represent nestable data structures, such as:

• Elements in a vector graphic that supports nested grouping (e.g. SVG, geojson)
• Comments in a threaded comment format

It should be possible to move elements from one section of the tree to another. In order to handle this nicely, it probably makes sense to have one "pool" for the Tree, mapping uuids to interior state machines, and then have a nested structure of TreeNodes that refer to those uuids. This means that we need to make sure loops are broken and (equivalently) that every node has a parent in the tree.