Re: [encoding] Serializing internal TextDecoder state? (#7)

@domenic, I'd like to hear a more detailed explanation of the use case: Why do streams need to stay logically open across a service worker upgrade?

@annevk In Gecko, the way the state is stored is considered private to the decoder and the different decoders don't have a consistent representation. One way to deal with this would be to rewrite all our decoders to be stateless (turn them from classes to mere functions basically) and to introduce a separate common state management wrapper for all the callers that don't need to deal with the state themselves.

Apart from requiring rewriting all the decoders (which I think we should do anyway--in Rust; I'm working on a proposal), there's the sadness that ISO-2022-JP's state is different from all the others. For everything else, the state would be zero to three bytes. Except for ISO-2022-JP. :-(

Now, just because I'm working on a proposal for a rewrite doesn't mean we'll do one or that we'll do one soon. And even if a rewrite made serializing the state feasible, I'm still skeptical of the merit of the use case for making the state serializable.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/7#issuecomment-153085014