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

[Eric Bidelman]

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]

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]

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]

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]

Ah, ok. Thanks Paul and macrojd.

[Jenn Cook]

what is BLOB?