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

Re: New draft of FileWriter API posted

From: Eric Uhrhane <ericu@google.com>
Date: Thu, 15 Apr 2010 17:31:30 -0700
Message-ID: <s2p44b058fe1004151731x59be6f30of013020ac382ff05@mail.gmail.com>
To: Kinuko Yasuda <kinuko@chromium.org>
Cc: Dmitry Titov <dimich@chromium.org>, "Michael A. Puls II" <shadow2531@gmail.com>, public-device-apis@w3.org
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'?

I'm fine with that.  Anything else you can always do yourself.

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

Okeydoke; I'll update the spec.

>> 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):
>>>
>>> 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.
>>> 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:32:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:43 UTC