Media File System API
I work on Chrome at Google and a few of us have been working on a proposal to enable access to local media files - http://goo.gl/L8zXT . A number of different ideas [1, 2, 3] have floated around to address this issue so it seems there is interest but no consensus on the right approach. We have come to the conclusion that using the File system API to make media files available will most easily integrate with the web platform. Aside from providing a method to get the media file systems, our API addresses the problem of interaction with media file-metadata. It adds mechanisms to read and write and search that metadata that are not media specific and could be used for other file types. Accessing user's media files from webapps raises a number of privacy concerns. To help address this, the getMediaFileSystems function is asynchronous; the user agent can interact with the user in what ever way it likes to ensure that they want to grant the given origin access to their files before providing a result to the page. Furthermore, being able to write to a user's media collections raises security issues. In some ways, writing to media collections is similar to a user downloading files from the web. On the other hands, less user interacting (if any) is required so the user may not be aware of these transfers. We're still working out how to mitigate these potential security issues, but some ideas include setting the from internet bit of files modified through the API, and ensuring that only media file extensions are allowed so that only appropriate viewers will be invoked, It'd be great to get feedback on this API (http://goo.gl/L8zXT) and how the various proposals can come together. -- Steve [1] https://wiki.mozilla.org/WebAPI/DeviceStorageAPI [2] https://dvcs.w3.org/hg/dap/raw-file/16185b62381d/gallery/index.html [3] http://dev.w3.org/2009/dap/gallery/
Re: Bug Tracking for the File* specs [Was: Re: Bug in file system Api specification]
On Wed, Dec 21, 2011 at 4:05 AM, Arthur Barstow art.bars...@nokia.comwrote: Hi Brona, For mostly historical reasons, WebApps' File* specs still use Tracker rather than Bugzilla (and IIRC, Arun also uses the list archive as well as the spec itself to track issues for the File API spec): http://www.w3.org/2008/**webapps/track/productshttp://www.w3.org/2008/webapps/track/products For consistency, it would be good to move these specs to Bugzilla but I also don't want to create any make work for the Editors. (Arun, Jonas, EricU - if you want Bugzilla components for these specs, please let me know and I'll ask MikeSmith to create them.) FYI - I previously asked Jonas about this and he didn't seem to be aware of the Tracker entries and thought that lack of a Bugzilla component was just an oversight. So at least one of the editors probably wouldn't mind. I asked because I was trying to file a bug/feature request, which still isn't tracked anywhere. -- Steve -AB On 12/21/11 3:21 AM, ext Bronislav Klučka wrote: Hi http://www.w3.org/TR/file-**system-api/#widl-FileEntry-**filehttp://www.w3.org/TR/file-system-api/#widl-FileEntry-file says that successCallback is A callback that is called with the newFileWriter. there should be A callback that is called with the File BTW was trying to file that bug myself, but I could not find suitable component in WebAppsWG product. Brona
Re: Bug Tracking for the File* specs [Was: Re: Bug in file system Api specification]
On Mon, Feb 27, 2012 at 5:04 PM, Steve VanDeBogart vand...@google.comwrote: On Wed, Dec 21, 2011 at 4:05 AM, Arthur Barstow art.bars...@nokia.comwrote: Hi Brona, For mostly historical reasons, WebApps' File* specs still use Tracker rather than Bugzilla (and IIRC, Arun also uses the list archive as well as the spec itself to track issues for the File API spec): http://www.w3.org/2008/**webapps/track/productshttp://www.w3.org/2008/webapps/track/products For consistency, it would be good to move these specs to Bugzilla but I also don't want to create any make work for the Editors. (Arun, Jonas, EricU - if you want Bugzilla components for these specs, please let me know and I'll ask MikeSmith to create them.) FYI - I previously asked Jonas about this and he didn't seem to be aware of the Tracker entries and thought that lack of a Bugzilla component was just an oversight. So at least one of the editors probably wouldn't mind. I asked because I was trying to file a bug/feature request, which still isn't tracked anywhere. Sorry, I missed that this was already handled. Please ignore. -- Steve -AB On 12/21/11 3:21 AM, ext Bronislav Klučka wrote: Hi http://www.w3.org/TR/file-**system-api/#widl-FileEntry-**filehttp://www.w3.org/TR/file-system-api/#widl-FileEntry-file says that successCallback is A callback that is called with the newFileWriter. there should be A callback that is called with the File BTW was trying to file that bug myself, but I could not find suitable component in WebAppsWG product. Brona
Re: [File API] Other sources for Blob data.
On Thu, Dec 1, 2011 at 8:58 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Nov 29, 2011 at 4:09 PM, Steve VanDeBogart vand...@google.comwrote:
In several thought experiments using the File API I've wanted to create a
Blob for data that I haven't materialized. It seems that a way to create a
blob backed by an arbitrary data source would be useful. In particular, I
would like to see a blob constructor that takes a URL and size as well as
one that takes a callback.
A URL constructed blob could use a byte range request when a FileReader
requests a slice of the blob. i.e the internal implementation could be
reasonably efficient.
Note that since Blobs need to know their size when constructed,
constructing a blob like this would need to be async.
That would also imply that if you read a whole file this way, you're
always going to make two HTTP requests; a HEAD to determine the size and
then a GET.
This is why I suggested the constructor take a URL and a size, since you
might already know it. Though I guess with an async constructor the size
could be optional and if it isn't present a HEAD request could determine it.
A callback backed blob would be a bit more complicated. Maybe something
like the interface below, though you'd probably need another level of
indirection in order to deal with concurrency.
interface BlobDataProvider : EventTarget {
void getDataSlice(long long start, long long end);
void abort();
readonly attribute any result;
readonly attribute unsigned short readyState;
attribute [TreatNonCallableAsNull] Function? onloadstart;
attribute [TreatNonCallableAsNull] Function? onprogress;
attribute [TreatNonCallableAsNull] Function? onload;
attribute [TreatNonCallableAsNull] Function? onabort;
attribute [TreatNonCallableAsNull] Function? onerror;
attribute [TreatNonCallableAsNull] Function? onloadend;
}
FYI:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029998.html
FWIW, I was thinking along these lines:
interface BlobDataProvider : EventTarget {
void getSize(BlobDataProviderResult result);
void getDataSlice(long long start, long long end, BlobDataProviderResult
result);
}
As you say, since the size is an attribute of the blob, I don't see the
benefit to making it part of the callback... I guess unless you're trying
to support the streaming blob case. But maybe that's just an argument for
making it
an async function instead of an attribute in the Blob interface.
interface BlobDataProviderResult : EventTarget {
void result(any data);
void error();
attribute [TreatNonCallableAsNull] Function? onabort;
}
result can be called multiple times, to provide data incrementally.
Progress events are up to the browser.
That said, the only use case I've seen for it is weak DRM, which isn't
very interesting.
The use case I've been thinking about is getting metadata out of files. So
I may want to examine a slice at the beginning of a file and then,look at
other slices at the end or various places in the middle. For a local file,
not a problem, but if you want to integrate an online file provider, (drop
box or something else of that ilk), you can either use a file/callback
based blob, or build a second interface to accessing file data into your
webapp. It all feels cleaner and nicer if just a single interface can be
used.
It seems you've been following this issue longer than I, do you know of a
bug filed against the File API for something like this? If not, I'll
probably file one.
--
Steve
Re: [File API] Other sources for Blob data.
On Fri, Dec 2, 2011 at 1:07 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Dec 2, 2011 at 2:20 PM, Steve VanDeBogart vand...@google.comwrote:
interface BlobDataProvider : EventTarget {
void getSize(BlobDataProviderResult result);
void getDataSlice(long long start, long long end,
BlobDataProviderResult result);
}
As you say, since the size is an attribute of the blob, I don't see the
benefit to making it part of the callback... I guess unless you're trying
to support the streaming blob case. But maybe that's just an argument for
making it
an async function instead of an attribute in the Blob interface.
The getSize method could be removed here, and creating a blob this way
would be synchronous: Blob.fromProvider(myProvider, size, type). (I should
have removed the EventTarget base from BlobDataProvider, too.)
I don't know if there's any API precedent for passing in a user-created
object like this. (It's similar to WebIDL dictionaries, but I'm not sure
if that's meant for functions.) Anyway, the interface isn't really needed:
Blob.fromReader(myGetDataSliceFunc, size, type).
I haven't seen any other places where the javascript runtime satisfies a
request by calling a previously called function, but in this case it seems
like it could be done safely.
The use case I've been thinking about is getting metadata out of files.
So I may want to examine a slice at the beginning of a file and then,look
at other slices at the end or various places in the middle. For a local
file, not a problem, but if you want to integrate an online file provider,
(drop box or something else of that ilk), you can either use a
file/callback based blob, or build a second interface to accessing file
data into your webapp. It all feels cleaner and nicer if just a single
interface can be used.
It feels like a natural thing to provide, but I don't know if the use
cases so far are really that compelling.
Dropbox-like services don't really need to use a callback API; the
Blob-from-URL interface would probably be enough for that.
Indeed - the Blob-from-URL interface isn't as powerful, but it may be
sufficient.
Another use case to consider... I was looking at this API proposal:
http://dev.w3.org/2009/dap/gallery/#mediaobject Each media object is a file
(a blob). If I wanted to provide a cloud-backed gallery, I'd need some way
to make MediaObjects for each image/song/video. It'd be a real shame to
have to download an object just to provide a MediaObject, which the
consumer may or may not access.
It seems you've been following this issue longer than I, do you know of a
bug filed against the File API for something like this? If not, I'll
probably file one.
I don't know of anything beyond that earlier discussion.
I went to file a bug, but there doesn't seem to be a File API component to
file it against. I'll bug someone about that.
As an aside, in a sense Blob from URL is a natural inverse operation to
URL.createObjectURL.
Indeed, I hadn't noticed that.
--
Steve
[File API] Other sources for Blob data.
In several thought experiments using the File API I've wanted to create a
Blob for data that I haven't materialized. It seems that a way to create a
blob backed by an arbitrary data source would be useful. In particular, I
would like to see a blob constructor that takes a URL and size as well as
one that takes a callback.
A URL constructed blob could use a byte range request when a FileReader
requests a slice of the blob. i.e the internal implementation could be
reasonably efficient.
A callback backed blob would be a bit more complicated. Maybe something
like the interface below, though you'd probably need another level of
indirection in order to deal with concurrency.
interface BlobDataProvider : EventTarget {
void getDataSlice(long long start, long long end);
void abort();
readonly attribute any result;
readonly attribute unsigned short readyState;
attribute [TreatNonCallableAsNull] Function? onloadstart;
attribute [TreatNonCallableAsNull] Function? onprogress;
attribute [TreatNonCallableAsNull] Function? onload;
attribute [TreatNonCallableAsNull] Function? onabort;
attribute [TreatNonCallableAsNull] Function? onerror;
attribute [TreatNonCallableAsNull] Function? onloadend;
}
Alternatively, exposing the (internal) interface FileReader uses to
interact with a Blob would remove the magic from a Blob and let a user
synthesize their own blob.
--
Steve
