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

About the metadata issue #8

Closed
est31 opened this issue Nov 26, 2017 · 2 comments
Closed

About the metadata issue #8

est31 opened this issue Nov 26, 2017 · 2 comments

Comments

@est31
Copy link

est31 commented Nov 26, 2017

Vorbis comment headers appear in quite many places, in vorbis, opus and in flac. Even though parsing them is only very little code, I think one could create a crate to do the parsing. What do you think? Would you use it? If yes, I'll extract the parsing code from my lewton crate :).

@ruuda
Copy link
Owner

ruuda commented Nov 26, 2017

I would not use it; Claxon has zero dependencies and that is a feature.

There are two extremes for the scope of a library: on the one end, there are the big frameworks, and on the other hand there are “microlibraries” (libraries that contain just one or a few functions). Big frameworks are undesirable if you only need a small part of them, because you nonetheless need to download and compile the entire thing. But microlibraries are also undesirable: they too increase download and compile time (more requests, the metadata is often larger than the code itself, the build tool needs to start a compiler process, the linker needs to do more work, etc.). Furthermore, microlibraries put more burden on the end users: they now need to check for license compatibility, keep an eye out for vulnerabilities, read the changelogs, hope that the library supports the Rust version they use, etc.

Where the benefits of reuse start to outweigh the cost of adding a dependency, is something that people should decide for themselves. I personally think the cost of dependencies is often underestimated.

For Vorbis comments specifically, the code has already been written, so the main advantage would be that bugfixes or other improvements could be shared (I don’t expect any binary size advantages, because most of the code will be inlined). But as you say, there is very little code in the first place, so I do not expect this piece of code to need a lot of maintenance. Therefore I do not think the advantages outweigh the cost in this case.

@est31
Copy link
Author

est31 commented Nov 26, 2017

Okay, I see. I'll close this then, thanks for the reply.

@est31 est31 closed this as completed Nov 26, 2017
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

No branches or pull requests

2 participants