-
Notifications
You must be signed in to change notification settings - Fork 7
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
Should rust-uchardet depend on rust-encoding? #1
Comments
lifthrasiir/rust-encoding#64 is a variation over (1). How do you think about that? |
I'm pro solution 1. It shouldn't be too much work to split this crate; it lets consumers avoid downloading |
This ticket is on hold until somebody tells me, "Yes, there's a lightweight spinoff of |
Okay, seems like a different kind of issue than the one you proposed solving in the initial report? So ultimately the issue is, then, that |
Yeah, I'd love for there to be a standard list of ISO encodings we could use, but which didn't require pulling in a big dependency. Or we might limit ourselves to the WhatWG encodings, if there's some small, popular Rust crate we could use. This might actually require the maintainers of different encoding-related crates to sit down and decide on a plan. |
I'm deprecated |
It looks like
encoding
is rapidly becoming the encoding library of choice, anduchardet
would be much more useful if it could actually transcode data directly. We have several choices:uchardet
as a strictly low-level library, and create a new library which depends on both it andencoding
.encoding
, and let the linker decide whether or not to pull in all ofencoding
.encoding
, and create a second internal library that provides the low-level API without pulling in everything.I'm leaning towards (2), with the option of splitting out (3) at a latter date if somebody asks for it. But I'm open to suggestions.
The text was updated successfully, but these errors were encountered: