Re: [FileAPI] File.slice spec bug

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

Received on Wednesday, 13 April 2011 06:51:15 UTC