Skip to content

Conversation

@ximon18
Copy link
Member

@ximon18 ximon18 commented Nov 25, 2024

This allows callers to report progress, which is especially useful on very large zone files.

For example usage see NLnetLabs/dnst#35.

I'm not very happy with the inplace::Zonefile progress support, but due to the replacement of self via the Bytes split() operation, reset of the start variable and the iterator being mutably consumed by the caller, using a new position tracking variable and returning it via Entry seemed like one easy way of getting the progress information out to the iterating caller code.

Perhaps something like Iterator::enumerate() could be used instead to return the progress offset to the iteration loop?

If we keep the extra var returned with Entry it should probably be made into named struct fields instead of anonymous tuple fields, to be more self-evident what the usize value is. Also, the extra tuple field infects all call sites which is annoying as most don't care about it.

Note: This PR lacks progress notification for NSEC hashing, that should also be added.

Thoughts:

  • Progress reporting should be optional, so perhaps the callback should be Option.
  • Progress reporting has a cost, perhaps it should be emitted only every N units instead of for every unit change?

@ximon18 ximon18 requested a review from a team November 25, 2024 13:28
@ximon18 ximon18 changed the title Report zonefile parsing progress to the caller. Report zonefile parsing & signing progress to the caller. Nov 25, 2024
@ximon18 ximon18 force-pushed the report-signing-progress branch from 99e0d40 to 2a8816f Compare December 5, 2024 11:57
@ximon18 ximon18 changed the base branch from byo-signing-sorter-impl to multiple-key-signing December 19, 2024 08:25
@ximon18 ximon18 changed the base branch from multiple-key-signing to initial-nsec3-generation December 19, 2024 08:27
@ximon18 ximon18 self-assigned this Sep 15, 2025
@tertsdiepraam
Copy link
Contributor

@ximon18 this has some conflicts. Do we need to keep this around?

@ximon18
Copy link
Member Author

ximon18 commented Oct 30, 2025

This parser is currently used by Cascade so assuming these changes are part of the patches-for-nameshed-prototype branch then they benefit Cascade users.

Anyone using this "old" parser benefits from these changes so yes, however, we were planning to switch to the new-xxx parser which would replace this parser.

@partim
Copy link
Member

partim commented Oct 31, 2025

@ximon18, would you then mind fixing the conflicts and, if you feel the PR is ready for review, remove the draft status?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants