-
Notifications
You must be signed in to change notification settings - Fork 2
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
Status - Sept 2022 #1
Comments
As of now ESLint is using TS-Standard's configuration which is very strict. Next steps are going to be setting up code coverage with c8 which I have not looked at yet. After that will be looking at how to generate API docs with typedoc. I'm going to be looking for a solution that generates markdown files. It would be great to be able to finish these by the 10th of this month. After that is all set up I think the next steps will be first going over the code again to try and clean it up and getting it ready for new features. The first feature will probably have to do with replication. There will be some replication tests added that will try to be extensive. In the future there are plans to try using test-ground from protocol labs which allows for testing over a large simulated network. |
Been thinking more and I'll be working on database persistence before replication. Normally I would work on replication first but with future plans local persistence is better. |
Closing with #12 uncompleted |
Many of the project files have just been committed. Almost every source file has a unit tests for it.
Bi-directional iterative traversal of the merkle-dag has been implemented and tested thoroughly (although there is always more room for testing; especially crucial components like this). This is done by keeping all known entry cids inside of an adjacency list with incoming and outgoing links being tracked. Source files with respective unit tests:
Two key features still need to be added. They are persistence and replication. This means that currently the utility of Opal currently is only mutating local states in memory. The mentioned two features are key and are the priority this month.
On adding persistence, the goal will be to also allow for opening databases in O(1) time this includes the time before being able to edit the database. To do this the states of the a few different components will need to be persisted, specifically:
Unfortunately to this kind of usability will rely on more stateful-ness, at least as I understand the problem now. What is nice is that these states may be able to be verified as correct/up-to-date potentially by references hashes. In which case the components generating and editing those stats can be sure that everything is working.
Focus this month is building a solid project foundation:
The text was updated successfully, but these errors were encountered: