[Bug 16733] Drop 'endings'?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16733

--- Comment #21 from Glenn Maynard <glenn@zewt.org> 2012-06-26 21:07:00 UTC ---
(In reply to comment #20)
> I'm ok with providing an orthogonal API, but think that as long as default
> behavior is well defined in Blob constructors, we might be good to go here. 
> The legacy BlobBuilder API for line endings is carried forward into Blob
> constructors, with better defined defaults, including what happens under
> append.  
> 
> Does that pass muster, or should we still consider a line endings API that's
> orthogonal?  I actually don't mind the dictionary object in the Blob
> constructor.

(This isn't about removing the dictionary parameter--the "type" option is
unaffected.)

My concern isn't changed: it's confusing to have a line-endings option on the
Blob ctor that only works for some types of blobParts and silently does nothing
for others.

I agree with Simon (comment #18) that if native line endings are going to be
exposed at all, people are probably going to want to use it without having to
go through Blob to access it.  A "toNativeLineEndings(DOMString)" method will
be wanted anyway.

toNativeLineEndings() avoids the confusion, since its argument is explicitly
DOMString.  If we have it, there's no reason to put it in Blob as well.  "new
Blob([toNativeLineEndings(arg1)])" isn't materially worse for authors than "new
Blob([arg1], {endings: "native"})". (I find it a little cleaner, actually.)

Also, toNativeLineEndings also makes it a bit easier to pick and choose which
arguments you want converted, instead of having to construct multiple Blobs:

> var b1 = new Blob([x1], {endings: "native"});
> return new Blob([b1, x2]);

becomes

> return new Blob([toNativeLineEndings(x1), x2]);

Another thing: if {endings: "native"} is kept and we don't make it affect
ArrayBufferView now, we won't be able to do it later--it would be a breaking
change.  For example, in "new Blob([view, string], {endings: "native"})",
"view" might be data previously read from disk--already containing native line
endings--and "string" data that the user wants to append to the end.  This code
depends on "view" *not* being converted because it's an ArrayBufferView. 
Changing endings to work on "view" would cause the existing data in "view" to
be doubly-converted.

(toNativeLineEndings() doesn't have this problem; we can add a
toNativeLineEndings(ArrayBufferView) overload later, when use cases surface,
instead of having to decide now.)

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 26 June 2012 21:07:03 UTC