Skip to content
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

Big Refactor According to Updated Spec #44

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

XuJiandong
Copy link
Collaborator

@XuJiandong XuJiandong commented Mar 14, 2024

Reference C implementation: cryptape/omnilock#3

Changes:

  • add lazy reader support
  • API changed
  • add testing
  • add documents. make it ready for publishing
  • fix according to updated spec
  • add logs

Note to reviewers:

  1. special variables names, like i, j, ie, oe are from spec
  2. there are special comments like "step xxx" which are from spec too

@XuJiandong XuJiandong changed the title Big Refactor According to Omnilock's Implementation in C Big Refactor According to Updated Spec Mar 15, 2024
@XuJiandong XuJiandong marked this pull request as ready for review March 20, 2024 08:25
Reference C implementation:
cryptape/omnilock#3

Changes:

- add lazy reader support
- API changed
- add testing
- add documents. make it ready for publishing
- fix according to updated spec
- add logs
Copy link
Contributor

@mohanson mohanson left a comment

Choose a reason for hiding this comment

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

No obvious problems.

* Add testcases, about cobuild_normal_entry
* Add some cycles checks for normal and successful cases.
@XuJiandong XuJiandong requested a review from quake April 2, 2024 05:51
@xxuejie
Copy link

xxuejie commented Apr 22, 2024

Just a quick glance at this PR: I could get the underlying change, but at this stage, I wasn't so sure about the API change, where we moved completely into a callback based design, instead of Rust iterators. I fear this might be far too big a change. Even if we switch from current design to a lazy loader based design, I feel like we can still keep much of the current APIs, yes there might be one or two data structure change but that will pretty much be it.

I wonder if we need to completely overhaul this, especially when the updated API, looks quite messy to me.

@xxuejie
Copy link

xxuejie commented Apr 22, 2024

I do recommend that we split it into 3 smaller PRs:

  1. Necessary spec changes
  2. Lazy loader part
  3. (if needed) Finally, the API changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants