On Fri, Nov 4, 2011 at 1:56 PM, Joshua Bell <email@example.com>
After much (justifiable!) procrastination,ÂI've started putting a draft spec together for this functionality, with input from Ken Russell and some other willing reviewers. I've just posted it to:
The biggest outstanding issue raised (so far) is the behavior when encoding to a buffer that isn't large enough for the string.
Feedback appreciated, although we will probably redirect the discussion to a more appropriate list.
Can you give use-cases for detecting encodings? ÂIt seems dangerous to try and guess the encoding.
The uses I see for this functionality are things like encoding protobufs or extracting strings from mixed binary/text payloads (such as an XHR response or a WebSockets message) -- in either case, the encoding would be known by definition or you would likely identify the encoding in metadata for the message.
I don't like that the NULL character cannot be sent using this mechanism -- it seems that any valid character sequence should be supported. ÂTo do that, you could use 0xFF as the terminator for UTF8/ASCII or U+FFFF for UTF16 (no better choice than 0x00 for Latin1 though). ÂIt might be useful to support padding to a fixed length in the API.
Mostly tangential: Every time I use DataView, I keep wanting something like perl's pack/unpack built on top of it, so I think of what would be needed to support those sorts of operations.