1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123
// Copyright © 2021 The Radicle Link Contributors
#![warn(clippy::unwrap_used)]
//! # Collaborative Objects
//!
//! Collaborative objects are graphs of CRDTs.
//!
//! ## Basic Types
//!
//! The basic types that are found in `radicle-cob` are:
//! * [`CollaborativeObject`] -- the computed object itself.
//! * [`ObjectId`] -- the content-address for a single collaborative object.
//! * [`TypeName`] -- the name for a collection of collaborative objects.
//! * [`History`] -- the traversable history of the changes made to
//! a single collaborative object.
//!
//! ## CRU Interface (No Delete)
//!
//! The main entry for manipulating [`CollaborativeObject`]s is by
//! using the CRU like functions:
//! * [`create`]
//! * [`get`]
//! * [`list`]
//! * [`update`]
//!
//! ## Storage
//!
//! The storing of collaborative objects is based on a git
//! backend. The previously mentioned functions all accept a [`Store`]
//! as parameter. The `Store` itself is an accumulation of different
//! storage capabilities:
//! * [`object::Storage`]
//! * [`change::Storage`] -- **Note**: there is already an
//! implementation for this for [`git2::Repository`] for convenience.
//!
//! ## Resource
//!
//! The [`create`] and [`update`] functions take a `Resource`. It
//! represents the type of resource the collaborative objects are
//! relating to, for example a software project.
//!
//! ## History Traversal
//!
//! The [`History`] of a [`CollaborativeObject`] -- accessed via
//! [`CollaborativeObject::history`] -- has a method
//! [`History::traverse`] which provides a way of inspecting each
//! [`Entry`] and building up a final value.
//!
//! This traversal is also the point at which the [`Entry::author`]
//! and [`Entry::resource`] can be retrieved to apply any kind of
//! filtering logic. For example, a specific `author`'s change may be
//! egregious, spouting terrible libel about Radicle. It is at this
//! point that the `actor`'s change can be filtered out from the
//! final product of the traversal.
#[cfg(test)]
extern crate qcheck;
#[cfg(test)]
#[macro_use(quickcheck)]
extern crate qcheck_macros;
extern crate radicle_crypto as crypto;
extern crate radicle_git_ext as git_ext;
mod backend;
pub use backend::git;
mod change_graph;
mod trailers;
pub mod change;
pub use change::store::{Contents, Embed, EntryId, Manifest, Version};
pub use change::Entry;
pub mod history;
pub use history::History;
pub mod signatures;
use signatures::ExtendedSignature;
pub mod type_name;
pub use type_name::TypeName;
pub mod object;
pub use object::{
create, get, info, list, remove, update, CollaborativeObject, Create, Evaluate, ObjectId,
Update, Updated,
};
#[cfg(test)]
#[allow(clippy::unwrap_used)]
mod test;
#[cfg(test)]
#[allow(clippy::unwrap_used)]
mod tests;
/// The `Store` is an aggregation of the different types of storage
/// traits required for editing [`CollaborativeObject`]s.
///
/// The backing store being used is expected to be a `git` backend.
///
/// To get started using this trait, you must implement the following
/// for the specific `git` storage:
///
/// * [`object::Storage`]
///
/// **Note**: [`change::Storage`] is already implemented for
/// [`git2::Repository`]. It is expected that the underlying storage
/// for `object::Storage` will also be `git2::Repository`, but if not
/// please open an issue to change the definition of `Store` :)
pub trait Store
where
Self: object::Storage
+ change::Storage<
StoreError = git::change::error::Create,
LoadError = git::change::error::Load,
ObjectId = git_ext::Oid,
Parent = git_ext::Oid,
Signatures = ExtendedSignature,
>,
{
}