- From: Joshua Bell <jsbell@google.com>
- Date: Tue, 13 Aug 2013 11:28:28 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: WHATWG <whatwg@lists.whatwg.org>, kg@luminance.org, Chang Shu <cshu01@gmail.com>
On Mon, Aug 12, 2013 at 4:50 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Mon, Aug 12, 2013 at 12:16 PM, Joshua Bell <jsbell@google.com> wrote:
>
>> To recap history: early iterations of the Encoding API proposal did have
>> base64 but it was removed with the suggestion to extend atob()/btoa()
>> instead, and due to the confusion around the encode/decode verbs. If the
>> APIs were something like StringToBytesConverter::convert() and
>> BytesToStringConverter::convert() it would make more sense for encoding of
>> both text (use StringToBytes) and binary data (use BytesToString).
>>
>
> I thought about suggesting something like "StringToBytes", but that seems
> less obvious for the (probably) more common usage of encoding/decoding a
> String, and it's still a bit off (though not *strictly* wrong) for
> converting to UTF-16, UTF-32, etc. I tend to think the slightly
> unintuitive names of TextEncoder and TextDecoder aren't bad enough that
> it's worth renaming them.
>
For completeness, it's also worth bringing up
https://developer.mozilla.org/en-US/docs/Code_snippets/StringView which
started this round of discussion (over on blink-dev) which is another more
"neutral" API design for binary/string data interop. I haven't read it
deeply, but it looks like it doesn't handle the streaming case, but does
explicitly tackle base64 without overloading text encoding methods.
>
>> While we're re-opening this can of worms, there's been a request to add
>> a flush() method to the TextEncoder/TextDecoder objects, which would behave
>> the same as calling encode(null, {stream: false}) / decode(null,
>> {stream:false}) but make the code more readable. This fails the "adding a
>> new method for something that behaves exactly like something we already
>> have" test. Opinions?
>>
>
> I think you only need to say encode() and decode(), which is less of a
> win, especially since creating two ways of doing the same thing means that
> people have to learn both ways. Otherwise, they'll see code end with
> ".encode()" and not realize that it's the same as the ".finish()" they've
> been using.
>
True. (I need to go back through this and other feedback that's trickled in
and see if I'm mis-representing it, and see if there's anything else
lingering.)
>
> On Mon, Aug 12, 2013 at 6:26 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> I don't think that base64 encoding fits with the current
>> TextEncoder/Decoder API. Not because of names, but because base64
>> encoding is by nature opposite. I.e. the encoded format is in string
>> form, whereas the decoded format is in binary form.
>>
>
> The names are the only things that are opposite. TextEncoder is just a
> streaming String-to-binary-blob conversion API, and TextDecoder is just a
> streaming binary-blob-to-String API, and that's precisely what base64
> encoding and decoding are. That's the same whether you're converting
> String-to-base64 or String-to-UTF-8. The only difference is that the names
> we've given to those ideas are reversed here.
>
Yes.
>
> One thing that might need special attention is that U+FFFD error handling
> doesn't make sense for base64; errors should probably always be fatal.
>
Excellent point.
...
I believe we may experiment with "api-base64" and see if there are other
gotchas beyond this and the naming.
>
>
> --
> Glenn Maynard
>
>
Received on Tuesday, 13 August 2013 18:28:53 UTC