W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2010

Re: New draft of FileWriter API posted

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Thu, 11 Mar 2010 03:52:17 -0500
To: "Eric Uhrhane" <ericu@google.com>
Cc: public-device-apis@w3.org
Message-ID: <op.u9eaxdca1ejg13@sandra-svwliu01>
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");

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
Received on Thursday, 11 March 2010 08:52:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:06 GMT