Re: [FileAPI] File.slice spec bug

On Tue, Apr 12, 2011 at 11:50 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Apr 12, 2011 at 10:01 PM, Darin Fisher <darin@chromium.org> wrote:
> > On Tue, Apr 12, 2011 at 5:59 PM, Brendan Eich <brendan@mozilla.org>
> wrote:
> >>
> >> Darin's position is "leaning toward" not breaking compatibility with
> what
> >> Chrome has shipped for a while. That's one consideration. It can't be
> the
> >> only consideration, or there's no point having a discussion and whatever
> >> Chrome ships first is an instant standard.
> >
> > Agreed.  I certainly don't assert that whatever Chrome ships first should
> be
> > regarded as standard.  Our rapid release schedule depends on platform
> > features beginning life with a vendor prefix.  I believe that we goofed
> in
> > this case by not vendor-prefixing the slice method.  More on this
> below...
> >
> >>
> >> When we talked to Kenneth Arnold of Google about a typed array method
> that
> >> was more subtly misnamed "slice", he quickly worked with other WebGL
> folks
> >> to rename it to "subarray". That in spite of some support for the typed
> >> array "slice" method having shipped in some beta releases (at least; not
> >> sure if any final releases supported slice).
> >
> > s/Kenneth Arnold/Kenneth Russell/
> > WebGL was disabled by default (hidden behind a flag) up until Chrome 9.
>  It
> > was "trivial" to change the API from the point of view of Chrome prior to
> it
> > coming out from behind a flag.
> >
> >>
> >> The subtler differences between typed array's subarray (formerly named
> >> slice) and JS's Array slice:
> >>
> >> (a) The subarray method returns a view of mutable ArrayBuffer data, its
> >> elements alias the elements of the typed array from which it came. This
> is
> >> the big reason to avoid using "slice".
> >>
> >> (b)  While subarray takes (start, end) parameters and allows end to be
> >> omitted; and it handles negative indexes; it does not allow start to be
> >> omitted too, whereas JS (after Python) does.
> >>
> >> http://www.khronos.org/registry/typedarray/specs/latest/
> >>
> >>
> http://www.khronos.org/webgl/public-mailing-list/archives/1102/msg00028.html
> >>
> >> The DOM is full of crazy inconsistency from insta-standards in the
> >> mid-'90s, starting with my DOM level 0 work. That is not a good pattern
> to
> >> repeat now that we have more balanced market actors and the benefits of
> >> hindsight. We should try to agree on less inconsistent APIs and
> prototype
> >> them, but no single prototype implementation can create a standard. Only
> >> interoperable de-facto standards can do that.
> >>
> >> At this point we need to be completely concrete, no leaning one way or
> >> another:
> >>
> >> 0. Do nothing.
> >>
> >> 1. Should we change slice, possibly breaking Chrome-only content that
> >> detects it by name but does not test its functionality?
> >>
> >> 2. Should we rename slice, allowing Chrome to keep the old name for a
> >> while if it must?
> >>
> >> Solution 0 just leaves a noxious inconsistency on two counts: length not
> >> end as the second parameter, the lack of negative index support. Is
> there
> >> another difference with Array slice (which comes from Python and is in
> Ruby
> >> too)? What about optionality of the arguments?
> >>
> >> Doing 1 is simpler for future users who don't have to deal with the
> legacy
> >> that Chrome-only content might represent.
> >>
> >> Doing 2 avoids breaking any such legacy, but may increase the cognitive
> >> load for users who see the legacy and the new renamed method.
> >>
> >> What about negative indexes? Is there time to spec and implement these
> per
> >> Python/JS/Ruby?
> >>
> >> Without negative index support, the case for 2 is stronger again.
> >>
> >> If Blob slice returns an aliasing view onto mutable data instead of a
> >> copy, just as typed arrays' subarray method does, then the case for 2 is
> >> extremely strong.
> >
> > Blobs are views on immutable data.  WebKit's implementation will reject
> > reads on a Blob, which points to a file that has since been modified.
>  (This
> > should be part of the spec if it is not.)
> >
> >
> >>
> >> I do not see any mutator methods in
> >> http://dev.w3.org/2006/webapi/FileAPI/, but with the typed array
> precedent I
> >> didn't want to assume.
> >>
> >> I favor 1 if negative index and optional argument semantics can be made
> to
> >> match precedent, and assuming no way to mutate shared Blob/sub-Blob
> data.
> >>
> >> If not, I suggest 2, with "subBlob" or a better name -- that one hurts
> due
> >> to the shifted-B, but "subblob" seems also bad for the run-together
> "bb".
> >>
> >> /be
> >
> > One option we can consider is to rename Blob.slice to Blob.webkitSlice
> and
> > adopt the newer arguments.  I think we would want to similarly
> vendor-prefix
> > BlobBuilder and FileReader as those too are non-standard.  This change
> runs
> > just as much risk of breaking Chrome-specific content; however, the
> failure
> > mode (absence of a method) should be easier for apps to cope with.
> > I'm not stating that we will do this yet.  I'm just proposing it as
> another
> > approach to consider.  I'll discuss this idea with others on the team
> > tomorrow.
> > By the way, I'm not too concerned about having to fix Google web apps.
>  I'm
> > much more concerned about third-party, Chrome-specific content available
> as
> > either apps or extensions through the Chrome app store.  It is hard to
> grep
> > for instances of Blob.slice!!
>
> Removing Blob.slice and replacing it with Blob.prefixSlice for now
> sounds like a good idea. Once websites have migrated over to it we can
> re-introduce Blob.slice with the correct arguments.
>
> I'll look into what I can do for Firefox 4.0.1 tomorrow.
>
> / Jonas
>


On the WebKit side, we are going to move forward with renaming Blob.slice to
Blob.webkitSlice.
We will also be renaming window.BlobBuilder [1] to window.WebKitBlobBuilder
as we fear similar
churn with that interface.

We are going to leave FileReader alone as that appears to have shipped in
Firefox 3.6.  I don't
know if Firefox 3.6 had FileReaderSync, but we are also going to leave
FileReaderSync alone.

We are going to try to get this change into Chrome 11; however, we have a
very short window
of opportunity for that release.  As such it may not happen until Chrome 12.

It would be nice to hear from someone at Opera about their willingness to
commit to this change
as well.

Regards,
-Darin

[1] http://www.w3.org/TR/file-writer-api/#idl-def-BlobBuilder