Re: New draft of FileWriter API posted

Hi,

On Thu, Mar 11, 2010 at 1:52 AM, Michael A. Puls II <shadow2531@gmail.com>wrote:

> On Wed, 10 Mar 2010 21:29:11 -0500, Eric Uhrhane <ericu@google.com> wrote:
>
>  On Tue, Mar 9, 2010 at 11:53 PM, Michael A. Puls II
>> <shadow2531@gmail.com> wrote:
>>
>>> On Tue, 09 Mar 2010 21:51:28 -0500, Eric Uhrhane <ericu@google.com>
>>> wrote:
>>>
>>>  I've rolled in the feedback so far.  I've left the line endings as an
>>>> open issue for now.
>>>>
>>>
>>> What about doing like C does for writing files. You have text translated
>>> mode (the default) and binary mode. Binary mode writes things as-is and
>>> translated mode converts newlines to the platform format.
>>>
>>> With that said, I would think that the mode would be something you set
>>> before using write() on FileWriter, and not something append() does when
>>> building the blob.
>>>
>>
>> As the ending translation is only relevant to text, it makes sense to
>> keep it where the text conversion happens.  You could append a mixture
>> of text and binary data to a Blob; if you then wanted to translate the
>> line endings only on the text portion, there would be no way to sort
>> it out without excessive bookkeeping under the covers.
>>
>
> Yeh, you can do that in C by opening a file in binary mode, writing to it
> and reopening it in text translated + append mode and writing to it again
> etc.
>
> But, yeh, I see. You want to always write() in binary and just have the
> blob be like a stream buffer (that's written when you call write()) where
> the translation happens (if desired) when adding to the buffer.
>
> That's fine.
>
> So, then, it'd be like this:
>
> var bb = new BlobBuilder();
> bb.append("string representing binary data");
> bb.endings = "native";
> bb.append("text with newlines translated to native format");
> bb.endings = "transparent";
> bb.append("another string representing binary data");
> bb.endings = "lf";
> bb.append("text with newlines translated to \\n");
> bb.endings = "cr";
> bb.append("string representing binary data with newlines converted to
> \\r");
>

Hm, I've been missing this discussion.
So here do we assume that the text conversion happens when user calls
append(text)?

Actually the current spec can be read in either way (if I'm not missing
something):

   1. convert line-endings when we call getBlob(), i.e. last 'endings'
   setting always win; no matter how many times we change 'endings' before
   calling getBlob() it doesn't do anything until an array of bytes (=Blob) is
   actually created.
   2. convert line-endings every time we call append(text)

If we want to delay the actual conversion until its very end stage option 1.
will have an advantage.

If there's a popular use case where we want to have mixed line-endings in a
single Blob 2. may have a point.
(But we can still do this with option 1., by creating multiple Blobs and
appending them as blobs.)

Eric, can we include an explicit notion about assumed text conversion timing
in the spec?
Also if 1. is assumed I think having the option as an (optional) parameter
of getBlob() may be better to avoid confusion.



> Or, if 'endings' is dropped:
>
> function toNixNewline(s) {
>    return s.replace(/\r\n|\r/g, "\n");
> }
> function toWin32Newline(s) {
>    return s.replace(/\r\n|\r|\n/g, "\r\n");
> }
> function toNativeNewlines(s) {
>    var pf = navigator.platform.toLowerCase();
>    return pf == "win32" ? toWin32Newline(s) : toNixNewline(s);
> }
>
> var bb = new BlobBuilder();
> bb.append("string representing binary data");
> bb.append(toNativeNewline("text with newlines translated to native
> format"));
> bb.append("another string representing binary data");
> bb.append(toNixNewline("text with newlines translated to \\n"));
>
> I personally like the 'endings' way. That way, the code that does the
> translating is handled natively. Native code might be able to handle that
> more efficiently. And, the native code might be able to detect that native
> newline format easier. (I also wish FileReader tranlated newlines to \n.)
>
> As for translating newlines, <
> http://unicode.org/standard/reports/tr13/tr13-5.html> may be relevant.
>
> --
> Michael
>
>