Re: Lifetime of Blob URL

On Tue, 31 Aug 2010 01:22:45 +0200, Darin Fisher 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(). Of course, the F

[Bug 10130] The steps to "dispatch the event" within EventSource should first remove the LF from the data buffer before checking whether it is empty. Otherwise it can never be empty.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10130 Anne changed: What|Removed |Added Resolution|NEEDSINFO |INVALID --- Comment #2 from Anne 2010-08-3

FileSystem API - overwrite flag for copy/move?

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 th

Re: Lifetime of Blob URL

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

Re: Lifetime of Blob URL

On Mon, Aug 30, 2010 at 5:23 PM, Jian Li 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. That seems like

Re: Lifetime of Blob URL

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 wrote: > On Mon, Aug 3

Re: Lifetime of Blob URL

On Mon, Aug 30, 2010 at 5:14 PM, Dmitry Titov 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 possible that web

Re: Lifetime of Blob URL

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 m

Re: Lifetime of Blob URL

On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher wrote: > On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking wrote: >> >> On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan >> wrote: >> >> In addition, BlobError and BlobException sound better because these >> >> names >> >> are consistent with current "

Re: Lifetime of Blob URL

On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking wrote: > On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan > 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 ado

Re: Lifetime of Blob URL

On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan 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 rename >> File

Re: Lifetime of Blob URL

On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan wrote: > 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 e

Re: Lifetime of Blob URL

On Mon, Aug 30, 2010 at 11:14 AM, Jian Li wrote: > > > On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan wrote: > >> 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 proble

[Bug 10130] The steps to "dispatch the event" within EventSource should first remove the LF from the data buffer before checking whether it is empty. Otherwise it can never be empty.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10130 Ian 'Hixie' Hickson changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug 10128] Step 4 of the EventSource algorithm should reference the "fail the connection" algorithm.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10128 Ian 'Hixie' Hickson changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug 10127] EventSource does not need to deal with HTTP 3xx responses as they are dealt with by the fetching algorithm.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10127 Ian 'Hixie' Hickson changed: What|Removed |Added Status|NEW |RESOLVED CC|

Re: Lifetime of Blob URL

On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan wrote: > 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 e

Re: Lifetime of Blob URL

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, w