Skip to content
This repository has been archived by the owner on Apr 15, 2024. It is now read-only.

[v2.0] Branch Announcement Message #262

Merged
merged 11 commits into from
Jul 13, 2022

Conversation

DyrellC
Copy link
Contributor

@DyrellC DyrellC commented Jun 27, 2022

Description of change

Adds a new BranchAnnouncement type message that conveys linked and new Topic details. Separates the announcement logic into StreamAnnouncement and BranchAnnouncement.
Addresses #258

Type of change

  • Enhancement (a non-breaking change which adds functionality)

How the change has been tested

  • Examples have been adjusted to check for BranchAnnouncement messages while fetching
  • Updated Messages test
  • fmt and clippy

Copy link
Contributor

@arnauorriols arnauorriols left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking very good. Just a couple of things that I find missing, and I think we could have them in this same PR so that we can consider this functionality done already.

streams/src/api/user.rs Outdated Show resolved Hide resolved
// handling the message
self.state
.cursor_store
.insert_cursor(&topic, publisher.clone(), INIT_MESSAGE_NUM);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still won't "carry over" the permissions of the parent branch to the new branch. Do we want to implement it in this PR, or create a new one for this functionality? It essentially mean to get all cursors tracked in parent branch and init them in the new branch. Without having given it much thought, sounds easy enough to do it in this PR. It would require implementing some testing in the examples though, which might take a bit more time

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably reasonable to do that yeah. I'll look at implementing it in this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After some work/thought I think a different PR makes more sense.

streams/src/api/user.rs Outdated Show resolved Hide resolved
streams/src/api/message.rs Outdated Show resolved Hide resolved
streams/src/api/user.rs Outdated Show resolved Hide resolved
streams/src/api/user.rs Outdated Show resolved Hide resolved
streams/src/api/user.rs Outdated Show resolved Hide resolved
// If a message has been sent successfully, insert the base branch into store
self.state.cursor_store.new_branch(topic.clone());
// Commit message to stores
self.state
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

624-630 happen in here, handle_announcement and in handle_branch_announcement. Maybe we should make a method?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't hurt

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After examining it more closely I'm not sure that would work. When handling messages we store the cursor before unwrapping the message, and then store spongos if it was successful, whereas on sending we store the cursor and spongos one after another after the message sends properly.

Copy link
Contributor

@arnauorriols arnauorriols left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, from my side it's a go! This last comment can be addressed now, or when we implement the advanced message consumption

// Collect permissions from previous branch and clone them into new branch
let prev_permissions = self
.cursors()
.filter(|cursor| cursor.0 == &prev_topic)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This iterates the potentially very long set of all cursors in the StreamCan, just to filter those of an specific topic. We could easily have a (&Topic) -> impl Iterator<Item=(&Identifier, usize)> method that uses the HashMap instead

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright I added the function, just let me know if there's another change you want done to it, otherwise I'm ready to merge it whenever

Copy link
Contributor

@kwek20 kwek20 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes LGTM, lets merge @arnauorriols

@DyrellC DyrellC merged commit 49fddd2 into iotaledger:v2.0-dev Jul 13, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants