Jian,
On 8/28/10 8:59 PM, Jian Li wrote:
Adding explicit methods to window and WorkerGlobalScope seems to be a
better solution that solves potential problems we currently have with
blob.url. Given that, we're going to experiment the proposed new APIs
in the WebKit implementation, That is,
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10127
Ian 'Hixie' Hickson i...@hixie.ch changed:
What|Removed |Added
Status|NEW |RESOLVED
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10128
Ian 'Hixie' Hickson i...@hixie.ch changed:
What|Removed |Added
Status|NEW |RESOLVED
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10130
Ian 'Hixie' Hickson i...@hixie.ch changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, Aug 30, 2010 at 11:14 AM, Jian Li jia...@chromium.org wrote:
On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan a...@mozilla.comwrote:
Jian,
On 8/28/10 8:59 PM, Jian Li wrote:
Adding explicit methods to window and WorkerGlobalScope seems to be a
better solution that solves
On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan a...@mozilla.com wrote:
In addition, BlobError and BlobException sound better because these names
are consistent with current Blob naming scheme in File API. So we're also
going to adopt these new names in the WebKit implementation when we
On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan a...@mozilla.com
wrote:
In addition, BlobError and BlobException sound better because these
names
are consistent with current Blob naming scheme in File API. So we're
On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan a...@mozilla.com
wrote:
In addition, BlobError and BlobException sound better because these
names
As for wild ideas, it also could be something more generic, lets say
DataReader which can take Blobs and Files (and perhaps something else in the
future). Like XHR that has overloaded methods for xhr.open(..).
It seems possible that web developers may not realize that File is actually
a Blob and
On Mon, Aug 30, 2010 at 5:14 PM, Dmitry Titov dim...@chromium.org wrote:
As for wild ideas, it also could be something more generic, lets say
DataReader which can take Blobs and Files (and perhapsĀ somethingĀ else in the
future). Like XHR that has overloaded methods for xhr.open(..).
It seems
The other alternative is to have both FileReader and BlobReader, while the
former one is for reading only File object and the later one is for reading
any Blob object. With that, we also have FileReaderSync and BlobReaderSync.
On Mon, Aug 30, 2010 at 5:17 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Aug 30, 2010 at 5:23 PM, Jian Li jia...@chromium.org wrote:
The other alternative is to have both FileReader and BlobReader, while the
former one is for reading only File object and the later one is for reading
any Blob object. With that, we also have FileReaderSync and BlobReaderSync.
As a developer who eagerly awaits this API, I'm fine with using File-
prefixes for most everything, since many times a file in many APIs is
really an abstraction for a stream of data anyway, and I think that most
experienced developers can wrap their heads around that.
That's my two cent's worth,
Hi,
I have a question about Entry.moveTo/copyTo behavior defined in
the File API: Directories and System [1].
Currently the API doesn't specify how Entry.moveTo() and copyTo() should
behave
when a source entry is a file and there's *already* a file at the
destination path.
Should UAs overwrite
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10130
Anne ann...@opera.com changed:
What|Removed |Added
Resolution|NEEDSINFO |INVALID
--- Comment #2 from
On Tue, 31 Aug 2010 01:22:45 +0200, Darin Fisher da...@chromium.org
wrote:
Another idea (possibly a crazy one) would be to eliminate Blob, and just
use File for everything. We could rename BlobBuilder to FileBuilder and
have it return a File instead of a Blob. Same goes for Blob.slice().
16 matches
Mail list logo