Commit builder API - linking resources to commits

[joepio]

Atomic Commits describe how a resource is to be mutated. A Commit might mean the resource should be removed, it might mean some fields will be added, it might mean a single field is changed.

Constucting these Commits should be simple. Ideally, developers should not have to deal with commits - they should simply call "destroy" on some instance and it should be removed accordingly.

However, sometimes developers will need to manually create these commits. For example if a developer tries to batch various changes instead of sending the commit after a single change.

This asks for a nice API for building / constructing these commits.

let commit = Commit::new("mySubject");
commit.set("someprop", "someval");
commit.set("otherprop", "otherval");
commit.send();
// send makes sure the signature and timestamp are correct, and it's sent to the right places.

[joepio]

It might also make sense to give Resource instances a CommitBuilder. So when some data manipulation method is called on a resource, a Commit will be instantiated. Only when resource.commit() is called, the Commit will be constructed fully (including timestamp + signature) and it will be shared.

So perhaps a Resource has an Option<Commit>, which is constructed when calling resource.set(prop, val) for example.

[joepio]

The current implementation of storelike.commit indirectly uses Resource.save() - which is a dependency I think should be removed. Resources should probably only write stuff to the store using Commits. This ensures that the Commits are persisted and can be shared to other users.

[joepio]

I think I need to convert Resource into a trait, and have a ResourceLinked for providing the easiest API for external use, but create a ResourceOwned for using in the Commit function. This also fixes a problem where the commit throws an error after some set attributes are applied, but before all the Commit fields are processed - in other words, this would make it transactional.

[joepio]

Or... Instead of the above, where resource methods implicitly call Resource.save() on every update, I can make calling save explicit. Perhaps even better - I think this does not require a new trait.