Re: New draft of FileWriter API posted

On Fri, Apr 16, 2010 at 10:40 AM, Mike Clement <mikec@google.com> wrote:

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

Yes, 'transparent' is the default operation, so it would default to handling
the data as-is.

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