Re: New draft of FileWriter API posted

On Thu, Apr 15, 2010 at 5:21 PM, Kinuko Yasuda <kinuko@chromium.org> wrote:

> 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?
>

I can definitely imagine a scenario where I'd want to serialize a string as
binary into a Blob.  If "endings" is omitted, would it default to handling
the data as-is (i.e., binary)?


>
> 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
>>>>
>>>>
>>>
>>
>