-
Notifications
You must be signed in to change notification settings - Fork 1
Refactor conversations #40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
6c54bbd
2a9fe1c
572ae6d
2e48e49
0ca0bb9
cc6988d
0ddfd3f
a5943ae
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,76 @@ | ||
| use std::collections::HashMap; | ||
| use std::fmt::Debug; | ||
| use std::sync::Arc; | ||
|
|
||
| pub use crate::errors::ChatError; | ||
| use crate::types::{AddressedEncryptedPayload, ContentData}; | ||
|
|
||
| pub type ChatId<'a> = &'a str; | ||
| pub type ChatIdOwned = Arc<str>; | ||
|
|
||
| pub trait HasChatId: Debug { | ||
| fn id(&self) -> ChatId<'_>; | ||
| } | ||
|
|
||
| pub trait InboundMessageHandler { | ||
| fn handle_frame( | ||
| &mut self, | ||
| encoded_payload: &[u8], | ||
| ) -> Result<(Box<dyn Chat>, Vec<ContentData>), ChatError>; | ||
| } | ||
|
|
||
| pub trait Chat: HasChatId + Debug { | ||
| fn send_message(&mut self, content: &[u8]) | ||
| -> Result<Vec<AddressedEncryptedPayload>, ChatError>; | ||
|
|
||
| fn remote_id(&self) -> String; | ||
| } | ||
|
|
||
| pub struct ChatStore { | ||
| chats: HashMap<Arc<str>, Box<dyn Chat>>, | ||
| handlers: HashMap<Arc<str>, Box<dyn InboundMessageHandler>>, | ||
| } | ||
|
|
||
| impl ChatStore { | ||
| pub fn new() -> Self { | ||
| Self { | ||
| chats: HashMap::new(), | ||
| handlers: HashMap::new(), | ||
| } | ||
| } | ||
|
|
||
| pub fn insert_chat(&mut self, conversation: impl Chat + HasChatId + 'static) -> ChatIdOwned { | ||
| let key: ChatIdOwned = Arc::from(conversation.id()); | ||
| self.chats.insert(key.clone(), Box::new(conversation)); | ||
| key | ||
| } | ||
|
|
||
| pub fn register_handler( | ||
| &mut self, | ||
| handler: impl InboundMessageHandler + HasChatId + 'static, | ||
| ) -> ChatIdOwned { | ||
| let key: ChatIdOwned = Arc::from(handler.id()); | ||
| self.handlers.insert(key.clone(), Box::new(handler)); | ||
| key | ||
| } | ||
|
|
||
| pub fn get_chat(&self, id: ChatId) -> Option<&(dyn Chat + '_)> { | ||
| self.chats.get(id).map(|c| c.as_ref()) | ||
| } | ||
|
|
||
| pub fn get_mut_chat(&mut self, id: &str) -> Option<&mut (dyn Chat + '_)> { | ||
| Some(self.chats.get_mut(id)?.as_mut()) | ||
| } | ||
|
|
||
| pub fn get_handler(&mut self, id: ChatId) -> Option<&mut (dyn InboundMessageHandler + '_)> { | ||
| Some(self.handlers.get_mut(id)?.as_mut()) | ||
| } | ||
|
|
||
| pub fn chat_ids(&self) -> impl Iterator<Item = ChatIdOwned> + '_ { | ||
| self.chats.keys().cloned() | ||
| } | ||
|
|
||
| pub fn handler_ids(&self) -> impl Iterator<Item = ChatIdOwned> + '_ { | ||
| self.handlers.keys().cloned() | ||
| } | ||
| } |
This file was deleted.
This file was deleted.
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| pub mod privatev1; | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As discussed I don't think converting this crate to legacy style modules adds any value, and makes working in the project more difficult. I understand there is not agreement on this topic, but I don't see a need to force this change now.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This crate clearly scope related logic in its own directory, without growing the files in src folder, and no need to just around to understand about the related logic.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
My main point is that this doesn't seem like a blocking item, it seems like personal preference. Given the current work load this seems low priority. There are many issues with imports and code structure which have larger impacts that we can agree on have benefit.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The restructure helps assemble my mind, the reason has been discussed in different places. And this is my overall plan to go through this journey,
|
||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't understand the motivation on flattening the "Conversation" folder which contained conversations into these hyper-specific root level modules.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Perhaps the part bothering you is the crate being named "conversations"? Would renaming that to "context", "client", "chat" help at all?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The confusing part is the unclear relationship between conversations and inbox, before make it clear, we should flatten the modules. Also I don't think the library will grow enough to the need of have 3 layers directory like
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like the idea to use chat to replace conversations. The flatten modules are still needed though. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| pub mod api; | ||
kaichaosun marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| // Group chat module |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -5,7 +5,7 @@ use blake2::{ | |
| use crypto::{DomainSeparator, PrekeyBundle, SecretKey, X3Handshake}; | ||
| use rand_core::{CryptoRng, RngCore}; | ||
|
|
||
| use crate::crypto::{PublicKey, StaticSecret}; | ||
| use crate::identity::{PublicKey, StaticSecret}; | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [Sand] I don't have a blocker here - but Identity doesn't seem like the correct place to manage Keys.
|
||
|
|
||
| type Blake2bMac256 = Blake2bMac<U32>; | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how "common" is an improvement. The crate already has a "utils", "types" files which are intended to hold components useful to many modules. Having all three makes it unclear of where code ought to live.
In this case,
Commondoesn't seem common at all. It seems only to pertain toConversationsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Common is shared by different types of conversations like inbox, dm and group chat.
The logos-chat (this crate) is about chat related protocols, and the major business logic is around inbox and dm, the common module is shared trait definitions depend by the major business.
The shared
typesmay also fit into common, but it may grow and better in split module for now.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously this code was in a file
conversation.rsand the conversation types were submodules that sub-modules of Conversation.Moving this code out of the Conversations Module seems to be the opposite of logically grouping business logic. It was contained logically and now its not.
Inbox is not a Conversation - Its the component which initializes conversations. It consumed the conversation module just as the Client module does. Though I will admit that Inbox is not perfect there is much to clean up after persistence is implemented.