Backwards incompatible changes to Blob.slice API, Prefixing of BlobBuilder and FileSystem APIs

954 views
Skip to first unread message

Eric Bidelman

unread,
Apr 22, 2011, 3:15:15 PM4/22/11
to Chromium HTML5
Hello,

Due to some pending changes to the W3C's Blob[1] specification, a
patch has recently landed in WebKit which will break backwards
compatibility for web pages, extensions, and apps which relied on
Chrome's implementation of the Blob.slice API. Also, to prevent this
type of breaking change in the future, several other File-related APIs
have been prefixed to signify that their APIs may change in the
future:

(Note: some of these changes will not appear until Chrome 12)

[1] BlobBuilder has been prefixed: window.BlobBuilder ->
window.WebKitBlobBuilder

See https://bugs.webkit.org/show_bug.cgi?id=58518

[2] Global FileSytem API methods have been prefixed:
window.requestFileSystem -> window.webkitRequestFileSystem
window.resolveLocalFileSystemURL ->
window.webkitResolveLocalFileSystemURL

See https://bugs.webkit.org/show_bug.cgi?id=58517

[3] Blob.slice has been prefixed and its semantics have changed to
that of Array.slice and String.slice (i.e. the second argument is a
byteoffset, not a length):

Blob.webkitSlice(
in long long start,
in long long end,
in DOMString contentType
);

See http://trac.webkit.org/changeset/83873

We regret having to break compatibility, but believe that making this
change early (before too many people depended on this implementation)
and moving to a prefixed model will be better for the web in the long
run. If you're interested in the discussion around these changes,
please see this thread[2].

Regards,
Eric

[1] http://www.w3.org/TR/FileAPI/#dfn-Blob
[2] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0170.html

Jordon Wii

unread,
Apr 23, 2011, 3:10:12 PM4/23/11
to Chromium HTML5
Just a quick question from the perspective of an app developer. Since
these changes will only affect Chrome dev users at first, then beta
and later stable at some point in the future, how would you suggest we
deal with the fact that some users will have the current
implementations, and others will have them with the changes listed
above?

In regards to the renaming, could one just do similar to this:

if (window.webkitRequestFileSystem) {
window.requestFileSystem = window.webkitRequestFileSystem;
}



On Apr 22, 12:15 pm, Eric Bidelman <ericbidel...@chromium.org> wrote:
> Hello,
>
> Due to some pending changes to the W3C's Blob[1] specification, a
> patch has recently landed in WebKit which will break backwards
> compatibility for web pages, extensions, and apps which relied on
> Chrome's implementation of the Blob.slice API.  Also, to prevent this
> type of breaking change in the future, several other File-related APIs
> have been prefixed to signify that their APIs may change in the
> future:
>
> (Note: some of these changes will not appear until Chrome 12)
>
> [1] BlobBuilder has been prefixed: window.BlobBuilder ->
> window.WebKitBlobBuilder
>
>     Seehttps://bugs.webkit.org/show_bug.cgi?id=58518
>
> [2] Global FileSytem API methods have been prefixed:
> window.requestFileSystem -> window.webkitRequestFileSystem
> window.resolveLocalFileSystemURL ->
> window.webkitResolveLocalFileSystemURL
>
>     Seehttps://bugs.webkit.org/show_bug.cgi?id=58517
>
> [3] Blob.slice has been prefixed and its semantics have changed to
> that of Array.slice and String.slice (i.e. the second argument is a
> byteoffset, not a length):
>
> Blob.webkitSlice(
>       in long long start,
>       in long long end,
>       in DOMString contentType
> );
>
>     Seehttp://trac.webkit.org/changeset/83873

Paul Irish

unread,
Apr 23, 2011, 4:07:38 PM4/23/11
to Jordon Wii, Chromium HTML5
On Sat, Apr 23, 2011 at 12:10 PM, Jordon Wii <jord...@gmail.com> wrote:
In regards to the renaming, could one just do similar to this:

if (window.webkitRequestFileSystem) {
 window.requestFileSystem = window.webkitRequestFileSystem;
}


You *could* but it's not wise. APIs are prefixed to allows vendor to change the API without worry, because people aren't using them heavily yet. There is no guarantee the API will stay the same when something goes from prefixed to unprefixed.  So you sign up to a little extra maintainability when using this edge features.

But mapping an experimental API to the standard namespace is probably not a wise choice. You can't really assume it'll stay the same and leave this as your future-proof code. :)

macrojd

unread,
Apr 23, 2011, 5:44:07 PM4/23/11
to Chromium HTML5

I think people in most cases do this instead:

if (window.webkitRequestFileSystem) {
mysystem = window.webkitRequestFileSystem;
} else {
mysystem = window.RequestFileSystem;
}

I saw that implementation in other APIs

JD

Jordon Wii

unread,
Apr 23, 2011, 9:31:52 PM4/23/11
to Chromium HTML5
Ah, ok. Thanks Paul and macrojd.

Jenn Cook

unread,
Oct 2, 2017, 5:21:09 PM10/2/17
to Chromium HTML5
what is BLOB?
Reply all
Reply to author
Forward
0 new messages