[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] String support in DataView
- To: Joshua Bell <email@example.com>
- Subject: Re: [Public WebGL] String support in DataView
- From: Glenn Maynard <firstname.lastname@example.org>
- Date: Tue, 27 Dec 2011 15:10:39 -0500
- Cc: email@example.com
- In-reply-to: <CAD649j6A0y9YWrrMMfDj4gNJfKCCdRm89VbnDR6YJ0TFOYTMnQ@mail.gmail.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <CABLsOLBmuaJcyy-nmok4wiWvZ7hdX+ci6HPN4QrccAP7WRDHGA@mail.gmail.com> <CAD649j6BExq2UAWwy9S67U_X6xT=bcC-Sy+YER9yHwoA7CfKBw@mail.gmail.com> <CABLsOLBzo-Pnuff2jn3AUp+bU_mmuHKJgXAQVHt1Rv97s+ESqQ@mail.gmail.com> <CABirCh-Mmj_qHg9NSY+t1W31uSqyq-LZp-OP+txC95EJU=rNQg@mail.gmail.com> <CAD649j6+D3EJhC3T3u97SDBC=gk2Ex59-GRSbrZVbeV2hYY_Vg@mail.gmail.com> <CABirCh9HvVEkwq9wbShFPgTbkQ-HT+M5Q5-p3JquEOPdCP4gEA@mail.gmail.com> <CABLsOLDUj+q6cTxis98tS220rM3SHP_QvQRJ9dGonM6KmY5NRg@mail.gmail.com> <CABirCh8bybn+by2_k_NwkPJ-NJfpDwQ3ycOL3FDxx0eEMO=Rbg@mail.gmail.com> <CABLsOLDh53hOSO986dpNCrmX1DM5zoi3oE5xMN8Yr=UGjP-fNw@mail.gmail.com> <CABirCh90qiaN33WTm-EBbC8h8FpH0n6aJ+hzcaws5vmk6KEP8g@mail.gmail.com> <CAD649j6bbLh0bL8xAv+rmbB0FfWRFHr_URutLUgGA9t8nsT72w@mail.gmail.com> <CABLsOLD+bR1dUOu2f53MDRHRouukYNFTvpY_mV6V3EpxswCN5A@mail.gmail.com> <CAKZ+BNo6K33GcWHn5jK6JXa4ibHT84nXQReWPZ0TVkdSy3ZyTg@mail.gmail.com> <CAD649j6A0y9YWrrMMfDj4gNJfKCCdRm89VbnDR6YJ0TFOYTMnQ@mail.gmail.com>
- Sender: firstname.lastname@example.org
On Tue, Dec 27, 2011 at 1:54 PM, Joshua Bell <email@example.com>
Hey folks - sorry for letting this linger again.
I'll pick up work on this draft in the new year. I'm leaning towards introducing an OptionsObject parameter on various methods that will allow for specifying:
FYI, Anne van Kesteren <firstname.lastname@example.org
> has started work on specifying the encodings themselves (discussion is over at whatwg). Once his work is further along, it'll probably be an obvious normative reference for details of the encodings themselves.
- Termination code points
- Termination byte sequences (exclusive with previous)
This is very monolithic. I think the API discussed earlier, with separate methods for for finding the end of the string, is much cleaner, and I don't think it has any notable drawbacks.
- Replacement character (throw instead if unspecified)
I'd replace by default. It's a less brittle default, since it won't fall over when people forget to test that code path (which will be common). For Unicode targets the replacement character should be U+FFFD; for others the normal default is ?.
I'm not sure how useful specifying a different replacement character is. I'd suggest having simply an "errors='fatal'" option, with a default of 'replace'. (Another possible option later on, if there's demand for it, would be HTML-escapes, which would replace unrepresentable characters with Ӓ escapes, along with escaping &. That only makes sense for encoding, not decoding.) If a different replacement character is useful, it can always be added as a separate option later on.