ord icon indicating copy to clipboard operation
ord copied to clipboard

Proposal to break ordinals crate and extract out Runestone and related modules from it.

Open twosatsmaxi opened this issue 2 months ago • 1 comments

  • In one of my project, I'm using Runestone struct and relate impl for deciphering a transaction but currently there is a fat crate Ordinals (https://docs.rs/ordinals/0.0.8/ordinals/) which has everything (including Runestone related modules).
  • Why not break it and have Runestone as an independent crate, there is one runestone = "0.0.0" but it's not maintained and it's not being used too in this repo?
  • This is also in the direction of moving rune related code out of ord (wasn't that the plan earlier?)
  • This will be a good refactor project for anyone to work on, I am also happy to take it up.

twosatsmaxi avatar Apr 30 '24 05:04 twosatsmaxi

What would be the goal of splitting out the runestone types into a separate crate? I don't think it would particularly improve compile times, since without tests, the ordinals crate is only 1600 lines of code. Presumably most projects that use the ordinals will have much heavier dependencies, so I don't think it would improve compile times much. I agree it would probably be slightly cleaner, but I think that's probably outweighed by the annoyance of having to remember to update more crates, and having more different places for code to live.

casey avatar Apr 30 '24 09:04 casey

What would be the goal of splitting out the runestone types into a separate crate?

Just for better segregation, I feel that it's easier to segregate them now than later when rune related code grows (and it'll grow I think), refactoring it later would be a pain. But this makes sense only if we are planning to extract out rune related code (not just crate but eveything else) out or ord. I do agree that there is a cost to it in maintaining it inititaly, but this'll give an idea and will be a starting point to extract rune out of ord.

twosatsmaxi avatar Apr 30 '24 14:04 twosatsmaxi

I think it's probably easier to split them when there's an actual problem that we want to solve. In general, I try not to anticipate problems too much, as long as they're not critical, since if you try to fix a problem you only might have in the future, it might never actually manifest.

casey avatar Apr 30 '24 19:04 casey