- From: Eric Uhrhane <ericu@google.com>
- Date: Thu, 15 Apr 2010 17:31:30 -0700
- 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