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.

Things are looking good for taking this change for Firefox 4.0.1!

So to be clear, here is the plan I propose:

Make implementations add a Blob.prefixSlice which uses the same
semantics as Array.slice and String.slice. Including support for
negative indexes and end being optional.

Change the spec to use the same semantics as Array.slice/String.slice.
Add a note to the spec describing the situation. I.e. that authors
should expect the function to be prefixed for now and that unprefixed
functions might be using bad semantics.

In a few months when we feel more comfortable with pages having gotten
updated, we'll add back File.slice but with Array.slice/String.slice
semantics. There is no real hurry to do this.

/ Jonas

Received on Wednesday, 13 April 2011 17:56:13 UTC