p2panda_sync

Trait TopicMap

Source 
pub trait TopicMap<T, S>:
    Debug
    + Send
    + Sync
where
    T: TopicQuery,
{
    // Required method
    fn get<'life0, 'life1, 'async_trait>(
        &'life0 self,
        topic: &'life1 T,
    ) -> Pin<Box<dyn Future<Output = Option<S>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait,
             'life1: 'async_trait;
}
Expand description

Maps a TopicQuery to the related data being sent over the wire during sync.

Each SyncProtocol implementation defines the type of data it is expecting to sync and how the scope for a particular session should be identified. Sync protocol users can provide an implementation of TopicMap so that scope S for data can be retrieved for a specific topic query T when a peer initiates or accepts a sync session.

Since TopicMap is generic we can use the same mapping across different sync implementations for the same data type when necessary.

§Designing TopicMap for applications

Considering an example chat application which is based on append-only log data types, we probably want to organise messages from an author for a certain chat group into one log each. Like this, a chat group can be expressed as a collection of one to potentially many logs (one per member of the group):

All authors: A, B and C
All chat groups: 1 and 2

"Chat group 1 with members A and B"
- Log A1
- Log B1

"Chat group 2 with members A, B and C"
- Log A2
- Log B2
- Log C2

If we implement TopicQuery to express that we’re interested in syncing over a specific chat group, for example “Chat Group 2” we would implement TopicMap to give us all append-only logs of all members inside this group, that is the entries inside logs A2, B2 and C2.

Required Methods§

Source

fn get<'life0, 'life1, 'async_trait>( &'life0 self, topic: &'life1 T, ) -> Pin<Box<dyn Future<Output = Option<S>> + Send + 'async_trait>>
where Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait,

Implementors§