Re: [File API] File behavior under modification

On Jul 11, 2012, at 10:02 PM, Glenn Maynard wrote: >> > What's the main problem with it being nullable? A fabricated date seems > strange, but instead of being nullable we could spec what the fabricated date > is. I'm just not totally sure what the pros and cons are here. > > If you call "d.

Re: [File API] File behavior under modification

On Wed, Jul 11, 2012 at 7:02 PM, Glenn Maynard wrote: > On Wed, Jul 11, 2012 at 2:53 PM, Arun Ranganathan > wrote: >> >> I agree that making snapshotting clearer might be a good idea. >> >> It is true that reading size and lastModifiedDate are synchronous, but >> this seemed a small trade-off com

Re: [File API] File behavior under modification

On Wed, Jul 11, 2012 at 2:53 PM, Arun Ranganathan wrote: > I agree that making snapshotting clearer might be a good idea. > > It is true that reading size and lastModifiedDate are synchronous, but > this seemed a small trade-off compared to data reads. > > My instinct is that an asynchronous API f

Re: [File API] File behavior under modification

Agreed. On Wed, Jul 11, 2012 at 1:02 PM, Arun Ranganathan wrote: > > On May 23, 2012, at 9:58 AM, Glenn Maynard wrote: > > On Wed, May 23, 2012 at 3:03 AM, Kinuko Yasuda wrote: >> >> Just to make sure, I assume 'the underlying storage' includes memory. > > > Right. For simple Blobs without a mu

Re: [File API] File behavior under modification

On May 23, 2012, at 9:58 AM, Glenn Maynard wrote: > On Wed, May 23, 2012 at 3:03 AM, Kinuko Yasuda wrote: > Just to make sure, I assume 'the underlying storage' includes memory. > > Right. For simple Blobs without a mutable backing store, all of this > essentially optimizes away. > > We shou

Re: [File API] File behavior under modification

Glenn, On May 22, 2012, at 11:48 AM, Glenn Maynard wrote: > On Tue, May 22, 2012 at 1:41 AM, Kinuko Yasuda wrote: > In my understanding WebKit's behavior is querying the metadata / reading the > content as lazy as possible, partly because the spec was/is ambiguous > (especially about when the

Re: [File API] File behavior under modification

Glenn: On May 21, 2012, at 9:44 PM, Glenn Maynard wrote: > On Mon, May 21, 2012 at 6:05 PM, Eric U wrote: > According to the latest editor's draft [1], a File object must always > return an accurate lastModifiedDate if at all possible. > "On getting, if user agents can make this information ava

Re: [File API] File behavior under modification

On Thu, May 24, 2012 at 8:27 AM, Jonas Sicking wrote: > On Mon, May 21, 2012 at 4:05 PM, Eric U wrote: > >> According to the latest editor's draft [1], a File object must always >> return an accurate lastModifiedDate if at all possible. >> "On getting, if user agents can make this information av

Re: [File API] File behavior under modification

On Mon, May 21, 2012 at 4:05 PM, Eric U wrote: > According to the latest editor's draft [1], a File object must always > return an accurate lastModifiedDate if at all possible. > "On getting, if user agents can make this information available, this > MUST return a new Date[HTML] object initialize

Re: [File API] File behavior under modification

On 5/23/2012 3:32 PM, Glenn Maynard wrote: On Wed, May 23, 2012 at 12:57 PM, Charles Pritchard > wrote: I think that's where the spec writing for this is challenging. I'd lean toward documenting what's really out there instead of mandating snapshot capabilitie

Re: [File API] File behavior under modification

On Wed, May 23, 2012 at 12:57 PM, Charles Pritchard wrote: > I can't imagine that Mozilla's behavior here is intended. Only by > returning a live mtime can authors be aware of whether or not the file has > changed from a previous state. > No, you can find out simply by requesting a read (even a

Re: [File API] File behavior under modification

On May 23, 2012, at 6:58 AM, Glenn Maynard wrote: > On Wed, May 23, 2012 at 3:03 AM, Kinuko Yasuda wrote: > Just to make sure, I assume 'the underlying storage' includes memory. > > Right. For simple Blobs without a mutable backing store, all of this > essentially optimizes away. > > We shou

Re: [File API] File behavior under modification

On Wed, May 23, 2012 at 3:03 AM, Kinuko Yasuda wrote: > Just to make sure, I assume 'the underlying storage' includes memory. > Right. For simple Blobs without a mutable backing store, all of this essentially optimizes away. We should also make it clear whether .size and .lastModifiedDate shou

Re: [File API] File behavior under modification

On Wed, May 23, 2012 at 12:48 AM, Glenn Maynard wrote: > On Tue, May 22, 2012 at 1:41 AM, Kinuko Yasuda wrote: > >> In my understanding WebKit's behavior is querying the metadata / reading >> the content as lazy as possible, partly because the spec was/is ambiguous >> (especially about when the

Re: [File API] File behavior under modification

On Tue, May 22, 2012 at 1:41 AM, Kinuko Yasuda wrote: > In my understanding WebKit's behavior is querying the metadata / reading > the content as lazy as possible, partly because the spec was/is ambiguous > (especially about when the file metadata should be captured) and also we > didn't want to

Re: [File API] File behavior under modification

On Mon, May 21, 2012 at 6:05 PM, Eric U wrote: > According to the latest editor's draft [1], a File object must always > return an accurate lastModifiedDate if at all possible. > "On getting, if user agents can make this information available, this > MUST return a new Date[HTML] object initialize

[File API] File behavior under modification

According to the latest editor's draft [1], a File object must always return an accurate lastModifiedDate if at all possible. "On getting, if user agents can make this information available, this MUST return a new Date[HTML] object initialized to the last modified date of the file; otherwise, this