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

Refactor: Move parsing into its own module #214

Open
carlaKC opened this issue Jan 27, 2025 · 0 comments
Open

Refactor: Move parsing into its own module #214

carlaKC opened this issue Jan 27, 2025 · 0 comments
Labels
Code Health Refactors and improvements to the structure of the code good first issue Good for newcomers

Comments

@carlaKC
Copy link
Contributor

carlaKC commented Jan 27, 2025

As is: we have a monolith main function that performs all parsing and creates a simulation.

Motivation: if using simln as a library, it would be nice to have a parsing module in sim-cli/src/parsing.rs to pull in some of the parsing/validation that main currently performs.

Some suggestions for things that we can pull out in a refactor:

  • Cli: move into module so that it can be re-used externally
  • SimParams: move to parsing module (it doesn't belong in the lib) (also move NodeConnection and ActivityParser)
  • get_clients: builds the map of dyn LightningNode that'll be passed to the simulation
  • validate_activities: performs ActivityParser -> ActivityDefinition conversion
  • read_sim_path: this is a nice to have frill, might as well make it accessible for other folks

The only thing that's tricky here is that validate_activities needs to make calls to our dyn LightningNode to validate that pubkeys exist in their graph, so that needs to be threaded through. Ideally this could just be a generic closure that looks up the node, but it gets ugly when you start dealing with async closures (I briefly tried this in the past and gave up).

@carlaKC carlaKC added Code Health Refactors and improvements to the structure of the code good first issue Good for newcomers labels Jan 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Code Health Refactors and improvements to the structure of the code good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant