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

Should rust-uchardet depend on rust-encoding? #1

Closed
emk opened this issue Nov 21, 2014 · 6 comments
Closed

Should rust-uchardet depend on rust-encoding? #1

emk opened this issue Nov 21, 2014 · 6 comments

Comments

@emk
Copy link
Owner

emk commented Nov 21, 2014

It looks like encoding is rapidly becoming the encoding library of choice, and uchardet would be much more useful if it could actually transcode data directly. We have several choices:

  1. Keep uchardet as a strictly low-level library, and create a new library which depends on both it and encoding.
  2. Depend on encoding, and let the linker decide whether or not to pull in all of encoding.
  3. Depend on 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.

@lifthrasiir
Copy link

lifthrasiir/rust-encoding#64 is a variation over (1). How do you think about that?

@sanmai-NL
Copy link

sanmai-NL commented Jul 25, 2017

I'm pro solution 1. It shouldn't be too much work to split this crate; it lets consumers avoid downloading encoding; it reduces the LTO slowdown. This is what I presume. What is the status of this ticket? (Wondering since it's almost 3 years old and the only open one.)

@emk
Copy link
Owner Author

emk commented Jul 25, 2017

This ticket is on hold until somebody tells me, "Yes, there's a lightweight spinoff of encoding that contains just the encoding names and not a lot of extra data." This might already exist, for all I know!

@sanmai-NL
Copy link

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 encoding should be split up rather than this crate? Feel free to correct me, I'm trying to gain an understanding of how I could help.

@emk
Copy link
Owner Author

emk commented Jul 26, 2017

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.

@emk
Copy link
Owner Author

emk commented Nov 28, 2017

I'm deprecated rust-uchardet in favor of the Rust chardet crate, which is a port of basically the same code to native Rust. So this issue is now moot. Thank you!

@emk emk closed this as completed Nov 28, 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

3 participants