feat(iroh-dns-server): Add evictable dns store #2994
Closed
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.
Description
Sort of some progress towards #2912, although for an in-memory store only. I don't think these changes can really be extended to a persistent one so it might be better to come up with a strategy that works for persistent and in-memory stores instead of this.
Breaking Changes
Notes & open questions
To be honest I'm not sure why I refactored the store to be a trait - I think it's unlikely this dns server will actually be extended by others.
I have also not tested this change at all, and I'm also not sure how the
StoreType
actually looks in a config file (but this is definitely something that should be configurable - a user can't use the existing in-memory store without modifying the hardcoded value and recompiling the server).I'm not even particularly advocating for the
timedmap
crate here, I think we could use any implementation of a hashmap with eviction (https://crates.io/crates/delay_map, our own, etc.).Like previously mentioned, I'm more interested in trying to figure out if we think it's worth adding something of this kind now and figuring out a solution for cleaning up the persistent store later, or if we want to figure out a solution entirely built on
redb
to keep the differences in the implementation smallChange checklist