On Tue, 7 Sep 2010, Darin Fisher wrote:
Based on the ValidityState example, it seems that the members of Flags
should be camelCase then instead of UPPERCASE?
The platform convention, insofar as there is a convention, is that
constants are uppercase, members are camelCase, and interfaces and
On Tue, Sep 7, 2010 at 11:13 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 7 Sep 2010, Darin Fisher wrote:
Based on the ValidityState example, it seems that the members of Flags
should be camelCase then instead of UPPERCASE?
The platform convention, insofar as there is a convention, is that
Hi Eric,
(re-sending from the correct address)
I've been re-reading the spec and started wondering if we really want to
have a new interface / javascript object for Flags.
The Flags interface is used to specify two behavioral options (CREATE and
EXCLUSIVE) for DirectoryEntry.getFile and
On Tue, Sep 7, 2010 at 12:41 AM, Kinuko Yasuda kin...@chromium.org wrote:
Hi Eric,
(re-sending from the correct address)
I've been re-reading the spec and started wondering if we really want to
have a new interface / javascript object for Flags.
The Flags interface is used to specify two
On Tue, Sep 7, 2010 at 6:07 PM, Eric Uhrhane er...@google.com wrote:
On Tue, Sep 7, 2010 at 12:41 AM, Kinuko Yasuda kin...@chromium.org wrote:
Hi Eric,
(re-sending from the correct address)
I've been re-reading the spec and started wondering if we really want to
have a new interface /
On Tue, 7 Sep 2010, Adam Barth wrote:
I think the bitfield approach is better. The current approach doesn't
work very well in strongly typed languages. Although we might think
that these APIs will be used most-often from JavaScript, these APIs are
language neutral and should work in a
On Tue, Sep 7, 2010 at 8:41 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 7 Sep 2010, Adam Barth wrote:
I think the bitfield approach is better. The current approach doesn't
work very well in strongly typed languages. Although we might think
that these APIs will be used most-often from
Hi Eric,
On Jul 8, 2010, at 03:50 , Eric Uhrhane wrote:
Robin:
- data stored there by the application should not be deleted by the
UA without user intervention, UA should require permission from the
user, The application may of course delete it at will - these
sound like real conformance
Hi Eric,
Thanks for your reply.
Actually after sending that email I had started to think that caching isFile
/ isDirectory information in memory would be ok if user could get an
informative error code when an entry becomes stale -- and seems like that's
the case. So I'm almost convinced :)
One
On Fri, Aug 13, 2010 at 10:58 AM, Eric Uhrhane er...@google.com wrote:
On Thu, Aug 12, 2010 at 11:08 PM, Kinuko Yasuda kin...@chromium.org
wrote:
Hi Eric,
Thanks for your reply.
Actually after sending that email I had started to think that caching
isFile
/ isDirectory information in
Fixed.
While I was in there, I deleted an unused class [FileSystemsCallback]
and changed the boolean persistent parameter [from requestFileSystem
and requestFileSystemSync] to be a more-general flag, to allow for
future expansion.
Eric
On Fri, Aug 13, 2010 at 11:23 AM, Kinuko Yasuda
My apologies for the slow response; I'm now back from my vacation.
On Tue, Jul 20, 2010 at 6:27 PM, Kinuko Yasuda kin...@google.com wrote:
Hi Eric,
Thanks for brushing up the draft.
We had some internal discussion about the API details and came up with a
question regarding is{File,Directory}
Hi Eric,
Thanks for brushing up the draft.
We had some internal discussion about the API details and came up with a
question regarding is{File,Directory} attributes of Entry interface.
It seems like user agent needs to be able to tell if a given entry is file
or directory synchronously (or from
I've posted a new draft of File API: Directories and System [1]. In
this draft I've rolled in quite a bit of feedback that I received
since first posting it on DAP--many apologies for the delay. This is
the first draft produced since we agreed to move this spec from DAP to
WebApps; I hope those
14 matches
Mail list logo
