Re: New draft of FileWriter API posted

Thanks for making points clearer.

On Thu, Apr 15, 2010 at 2:18 PM, Dmitry Titov <dimich@chromium.org> wrote:

> Good point, this is indeed unclear.
>
> There was some mixed reaction to 'endings' in this thread... I can see why
> one could need automatic transform of '\n' characters to 'native', but to
> 'cr'? It seems it goes against the idea that we are adding this property to
> avoid exposing what actual file system we are writing the file into. Also,
> 'lf, 'cr' and 'crlf' can all be done in script (and I don't know a good use
> case for that anyways).
>
> So how about reducing the range of values to just 2: 'transparent' and
> 'native'?
>

That sounds enough to me for incoming data that is to be stored on the local
filesystem.
How about for outgoing data?   Will there be a situation like someone wants
to send text as binary (via xhr using blobs built by BlobBuilder) to remote
servers where some particular ending (like 'lf') is assumed?

Separately, to address Kinuko's question, how about adding this value as an
> optional parameter of BlobBuilder.append(DOMString, [optional] endings)
> rather then a property of BlobBuilder?
>

Oh, I agree with this, It would make things clearer and meet various needs.

Thanks,



> Dmitry
>
>
> On Wed, Apr 14, 2010 at 4:55 PM, Kinuko Yasuda <kinuko@chromium.org>wrote:
>
>> 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
>>>
>>>
>>
>

Received on Friday, 16 April 2010 00:22:17 UTC