radicle-cob 0.20.0

Radicle Collaborative Objects library
Documentation 
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

// Copyright © 2021 The Radicle Link Contributors

#![deny(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 git_ref_format_core as fmt;
extern crate radicle_crypto as crypto;
extern crate radicle_dag as dag;
extern crate radicle_git_metadata as metadata;
extern crate radicle_oid as oid;

mod backend;

#[cfg(all(any(test, feature = "test"), feature = "git2"))]
pub use backend::git;

#[cfg(feature = "stable-commit-ids")]
pub use backend::stable;

mod change_graph;
mod trailers;

pub mod change;
pub use change::Entry;
pub use change::store::{Contents, Embed, EntryId, Manifest, Version};

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::{
    CollaborativeObject, Create, Evaluate, ObjectId, Update, Updated, create, get, info, list,
    remove, update,
};

#[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`]
///
pub trait Store
where
    Self: object::Storage
        + change::Storage<ObjectId = oid::Oid, Parent = oid::Oid, Signatures = ExtendedSignature>,
{
}