-
Notifications
You must be signed in to change notification settings - Fork 41
refactor(noq): change the way a disabled token store or token log is represented internally #697
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
Open
rklaehn
wants to merge
4
commits into
main
Choose a base branch
from
rklaehn/refactor-token-log-2
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
7c0bf48
Switch from Arc<dyn ...> to Option<Arc<dyn ...>> to make it visible
rklaehn c76925f
Add ways to disable both the client side token store and the server s…
rklaehn f4bf3ad
Merge branch 'main' into rklaehn/refactor-token-log-2
rklaehn fd5bc91
Merge branch 'main' into rklaehn/refactor-token-log-2
rklaehn File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Some comments aren't visible on the classic Files Changed page.
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
After checking more, this would introduce an API that doesn't follow the style of the rest. As you pointed out, this would rather by an
Option, making the whole API slightly more inconsistent. And we would be forced to maintain this api during 1.0.I hope I'm not wrong, but can't we make
send=0disable this? It seems to me both achieve the same, and having a positive value insent, means sending NEW_TOKEN frames that will be ultimately be ignored/considered unvalidated.If that is a correct route - which I'm not sure, I'm learning on the go to review this PR - it would save us one inconsistent api to support and maintain
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.
Hm, send=0 means eliminating sending tokens. But you would still have the store, which will rarely get a token to store (we don't accept tokens from previous instances of the remote endpoint, even though this would be allowed by the QUIC spec, so it would have to be the same instance of the remote but a new instance of the server side with send=0).
So all else being equal I would prefer the option route. The reason being that I don't even want an instance of the thing created if the mechanism provides very little benefit for normal iroh connections. But it isn't a big deal one way or another.
Maybe a better route would be to add in the future a
fn token_log(&mut self, log: Option<Arc<dyn TokenLog>>) -> &mut Selfand deprecate the somewhat weirdly namedpub fn log(&mut self, log: Arc<dyn TokenLog>) -> &mut Self {.Same with the client side: add
pub fn token_store_opt(&mut self, store: Option<Arc<dyn TokenStore>>) -> &mut Self {and deprecatepub fn token_store(&mut self, store: Arc<dyn TokenStore>) -> &mut Self {.Now if we are still allowed to do breaking changes I would do:
remove
fn log- the name is very generic. And add fn token_log(&mut self, log: Option<Arc>) -> &mut Self`change signature of
pub fn token_store(&mut self, store: Arc<dyn TokenStore>) -> &mut Self {to take an Option.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 agree that adding this method does break the style quite a bit. I don't have a lot of appetite for doing that at this point.
Also,
ValidationTokenConfig::logvsValidationTokenConfig::token_log. I honestly don't know which is weirder...And I don't think this meets the bar for breaking changes, but you're probably not surprised by that :)
IIUC the benefit is that you get so save a dyn call if you do not want a store? But this is only for new connections that do provide a token so very, very few. This is a rather marginal benefit compared to some API consistency questions. I'd be inclined to let the status-quo win and do nothing...
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.
The dyn call is too small to measure probably. The more important thing is being able to say, yes, this thing is definitely off, and return early.
The biggest win from doing this now and not later would be able to remove the two NoopTokenXXX rhings from the public API instead of having them laying around deprecated for a year.