vincenzopalazzo
/
arti
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

tor-circmgr: send_control_message: API change proposal 

I am hoping we can merge this as a "TODO (Diziet)",  even though I
think it may be controversial.  Ie merging this doesn't represent a
decision to do as I suggest.
This commit is contained in:
Ian Jackson 2023-06-05 12:45:25 +01:00
parent eecbf85b4c
commit e35d4e6a46
1 changed files with 21 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
crates/tor-proto/src/circuit.rs
View File

@ -305,6 +305,27 @@ impl ClientCirc {
/// while continuously monitoring for relevant incoming cells:
/// there will necessarily be a gap between `send_control_message` returning,
/// and being called again.
// TODO hs (Diziet): IMO the above limitation ^ shows the API is not right.
// There should probably be a separate function for when you're having
// a conversation, that *doesn't* mess with the handler.
// Something like this maybe:
// // This behaves like `send_control_message`, but the returned
// // future is a named type.
// //
// // Having two `Conversations` at once is forbidden.
// fn converse_directly(
// &self,
// msgs: impl Iterator<Item=AnyRelayCell>,
// reply_handler: impl MsgHandler + Send + 'static,
// ) -> Result<Conversation<'_>>;
// impl Future for Conversation<'_> {
// type Output = Result<()>; ....
// }
// impl Conversation {
// // `MsgHandler::msg_handler` gets a `Conversation<'_>` too
// // in case it wants to call this
// fn send_msg(&self, msg: AnyRelayCell> -> Result<()> {...}
// }
//
// TODO hs: rename this. "control_messages" is kind of ambiguous; we use
// "control" for a lot of other things. We say "meta" elsewhere in the