31, 2014 11:19 AM
To: Ali Alabbas
Cc: Web Applications Working Group WG
Subject: flush() | was Re: FileSystem API Comments
Greetings Ali!
I've been thinking about the discussion of flush(), and would like to see if I
can make my previous statement a bit more nuanced. It turns out that flush
the
Directory (e.g. add it to something like the OpeWriteOptions:
http://w3c.github.io/filesystem-api/Overview.html#widl-Directory-openWrite-Promise-FileHandleWritable--DOMString-File-path-OpenWriteOptions-options).
This way, the developer has the ability to “coin” a “more expensive” promise
On Tue Oct 21 09:36 PM, Jonas Sicking wrote:
1.1 Use cases (3. Audio/Photo editor with offline access or local
cache for
speed)
* Edited files should be accessible by other client-side
applications
- Having the sandboxed file system share its contents between all
apps
I don't see a contradiction.
Each *web* app sees only files accessible from its domain (so your two
apps have distinct pic.jpeg).
Each *native* app has access to whatever the operating system says.
Or am I missing something in your message?
Cheers,
David
On 22/10/14 12:23, Jonathan Bond-Caron
22.10.2014, 12:32, David Rajchenbach-Teller dtel...@mozilla.com:
I don't see a contradiction.
Each *web* app sees only files accessible from its domain (so your two
apps have distinct pic.jpeg).
Each *native* app has access to whatever the operating system says.
There are a lot of use cases
Ali,
First, thanks for your timely comments :) I’m in the process of editing the
FileSystem API.
Responses inline:
On Oct 21, 2014, at 4:36 PM, Ali Alabbas a...@microsoft.com wrote:
1.1 Use cases (3. Audio/Photo editor with offline access or local cache for
speed)
* Edited files
Hello,
I'm with the IE Platform team at Microsoft. We have a few comments on the
latest editor's draft of the newly proposed FileSystem API [1].
1.1 Use cases (3. Audio/Photo editor with offline access or local cache for
speed)
* Edited files should be accessible by other client-side
On 10/21/14 4:36 PM, Ali Alabbas wrote:
Hello,
I'm with the IE Platform team at Microsoft. We have a few comments on
the latest editor's draft of the newly proposed FileSystem API [1].
I believe [1] is Arun's http://w3c.github.io/filesystem-api/Overview.html.
1.1 Use cases (3. Audio
I am writing to give my feedback on the behavior of the FileWriter seek
function.
From
http://www.w3.org/TR/file-writer-api/#widl-FileWriter-seek-void-long-long-offset,
we see that for FileWriter.seek, If position length then set position to
length. (where length is the length of the file)
It
If the backend implementation used something like git's data store then
duplicate data would automatically be stored only once without any security
implications. The keys are the literal sha1 of the values. If two
websites had the same file tree containing the same files, it would be the
same
. (there are also gitlinks used
for submodules, but let's ignore those for now)
Sounds like IndexedDB is a better fit than a filesystem for this use case.
Note that the use case for the filesystem API isn't storing files,
IDB is perfectly capable of doing that. The use case for the
filesystem API
saying
that git is a great way to implement a filesystem and that git's abilities
are a great baseline for web filesystems.
Note that the use case for the filesystem API isn't storing files,
IDB is perfectly capable of doing that. The use case for the
filesystem API is to satisfy people
Yes. I completely agree. Personally in my projects, I wish there was to
create custom filesystems backed by JavaScript code that are exported to
hierarchical URLs. It would work somewhat like server-side web development
where a js function handles the request for a file. This is basically
On Wed, Nov 6, 2013 at 8:46 AM, pira...@gmail.com pira...@gmail.com wrote:
Yes. I completely agree. Personally in my projects, I wish there was to
create custom filesystems backed by JavaScript code that are exported to
hierarchical URLs. It would work somewhat like server-side web
is
open, deleting it on reload. I don't know of anything like to this,
the most similar ones would be FirefoxOS Browser API or Chrome
FileSystem API, but nothing as powerful as ServiceWorker, sorry :-(
They are talking about implementing the Fetch specification, maybe you
would write them about
for an web page to redirect URLs. This is
a very attractive feature for applications that are offline (or have an
unreliable connection). The redirected URL could be to a completely
different URL or to data managed by the ServiceWorker itself; eg, the
ServiceWorker could use the FileSystem API to store
-hotmail-yahoo-email-users/
2013/10/31 Brian Stell bst...@google.com:
In Request for feedback: Filesystem API [1] it says This filesystem
would
be origin-specific.
This post discusses limited readonly sharing of filesystem resources
between
origins.
To improve web site
On Thu, Oct 31, 2013 at 2:12 AM, Brian Stell bst...@google.com wrote:
There could be *dozens* of copies of exactly the same a Javascript library,
shared CSS, or web font in the FileSystem.
Check out the cache part of
https://github.com/slightlyoff/ServiceWorker/ Combined with a smart
I like Git's model :-)
This would de-dup the file storage but won't it require downloading it for
every domain (when the data is not lingering in HTTP cache)?
On Tue, Nov 5, 2013 at 11:45 AM, Tim Caswell t...@creationix.com wrote:
If the backend implementation used something like git's data
+1 to symbolic links, they have almost the same functionality that hard
links and are more secure and flexible (they are usually just plain text
files...).
El 30/10/2013 01:42, Brendan Eich bren...@mozilla.com escribió:
Hard links are peculiar to Unix filesystems. Not interoperable across all
Good points! I was thinking of the logical functioning and hadn't
considered the implementation. My understanding is that the UA will map
from the filename to an actual file using some kind of database. My
assumption was the logical idea of a link would happen in that layer.
On Wed, Oct 30, 2013
On most unix OSes, symbolic links are build using plain text files
with just the path where they point inside and no more data, and later
the OS identify them as a link instead a text file just by some
special file flags, no more. On Windows, the direct access (.lnk) has
a somewhat similar
What you are asking for could be fixed with redirects, that it's the
HTTP equivalent of filesystems symbolic links :-)
2013/10/31 Brian Stell bst...@google.com:
In Request for feedback: Filesystem API [1] it says This filesystem would
be origin-specific.
This post discusses limited readonly
I meant
eg, V1/dir1/file1, V2/dir1/file1.
Hard links are peculiar to Unix filesystems. Not interoperable across
all OSes. Symbolic links, OTOH...
/be
Brian Stell mailto:bst...@google.com
October 29, 2013 4:53 PM
I meant
eg, V1/dir1/file1, V2/dir1/file1.
Hi Jonas,
I notice that one of the common Linux file APIs, link[1], is not in you
API. I don't see this as a first pass requirement but I certainly expect
that applications will want to be able to have trees that represent a
particular version of their immutable files; eg, V1/dir1/file1,
vendor other than Mozilla actually interested in this
proposal? When it was brought up on public-webapps, and at the
WebApps F2F, it dropped with a resounding thud.
Given the standardization failure of the Chrome FileSystem API, this
could be a massive waste of time. Or it could just be a way
failure of the Chrome FileSystem API, this
could be a massive waste of time. Or it could just be a way for
Mozilla to document its filesystem API, since we've already got
documentation of the Chrome API, but then you don't need to drag
public-script-coord into that.
These are good questions
the standardization failure of the Chrome FileSystem API, this
could be a massive waste of time. Or it could just be a way for
Mozilla to document its filesystem API, since we've already got
documentation of the Chrome API, but then you don't need to drag
public-script-coord into that.
These are good
Greetings Eric and WG,
The Chair and I were discussing setting up repositories for the specifications
discussed here
(http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0307.html),
notably the FileSystem API and File API v2. Before creating a repository to
edit the FileSystem API
of public-webapps?
2) Is any vendor other than Mozilla actually interested in this
proposal? When it was brought up on public-webapps, and at the
WebApps F2F, it dropped with a resounding thud.
Given the standardization failure of the Chrome FileSystem API, this
could be a massive waste of time
:
Greetings Eric and WG,
The Chair and I were discussing setting up repositories for the
specifications discussed here
(http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0307.html),
notably the FileSystem API and File API v2. Before creating a repository to
edit the FileSystem API, we
Hell yes!!! +1000 to add an interface to inotify :-D
I'm concerned that you're taking this API too far. What's next -
mmaping a file to a byte array?
It would be cool... :-P
Ok, let's get serious. Maybe inotify would be too high level API and I
agree it would be moved to a later version,
On Sat, Jul 13, 2013 at 2:31 AM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Yesterday a few of us at mozilla went through the FileSystem API
proposal we previously sent [1] and tightened it up.
It was also pointed out that we should address multi-file locking too.
One of the options
, Jul 22, 2013 at 8:18 PM, Jan Varga jan.va...@gmail.com wrote:
On Sat, Jul 13, 2013 at 2:31 AM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Yesterday a few of us at mozilla went through the FileSystem API
proposal we previously sent [1] and tightened it up.
It was also pointed out
On Mon, Jul 22, 2013 at 11:18 AM, Jan Varga jan.va...@gmail.com wrote:
On Sat, Jul 13, 2013 at 2:31 AM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Yesterday a few of us at mozilla went through the FileSystem API
proposal we previously sent [1] and tightened it up.
It was also pointed
Adding something like inotify would also enable use cases like having
a worker synchronize a filesystem to a server. Other parts of the
application could simply access the filesystem directly and do
whatever modifications it wants. Those notifications will
automatically be noticed and
2013/7/22 pira...@gmail.com pira...@gmail.com:
Adding something like inotify would also enable use cases like having
a worker synchronize a filesystem to a server. Other parts of the
application could simply access the filesystem directly and do
whatever modifications it wants. Those
On Tue, Jul 23, 2013 at 4:48 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jul 22, 2013 at 11:18 AM, Jan Varga jan.va...@gmail.com wrote:
On Sat, Jul 13, 2013 at 2:31 AM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Yesterday a few of us at mozilla went through the FileSystem API
On Mon, Jul 22, 2013 at 3:40 PM, Janusz Majnert jmajn...@gmail.com wrote:
2013/7/22 pira...@gmail.com pira...@gmail.com:
Adding something like inotify would also enable use cases like having
a worker synchronize a filesystem to a server. Other parts of the
application could simply access the
On 15/07/13 23:26, Kinuko Yasuda wrote:
OTOH one limitation I could think of in not having JS object is it'll
disallow a possible future API expansion for sending a 'Directory'
object to another app by postMessage. (It's another popular request we
get in Chrome)
Isn't a Directory object just
On Thu, Jul 18, 2013 at 4:52 PM, Mounir Lamouri mou...@lamouri.fr wrote:
Isn't a Directory object just a path? I mean, would you send the list of
files and their content or just the path to the directory? If you
literally want to pass the Directory object, I am not sure how passing
the path is
Or simply if we make it possible to pass a Directory through
postMessage then you can open another website in a sandboxed iframe
and pass it a Directory and let it modify its contents, without having
to grant access to other parts of the sandboxed filesystem.
/ Jonas
On Thu, Jul 18, 2013 at 5:02
Glad to see this proposal has a new draft.
On Sat, Jul 13, 2013 at 9:31 AM, Jonas Sicking jo...@sicking.cc wrote:
Executive Summary (aka TL;DR):
Below is the mozilla proposal for a simplified filesystem API. It
contains two new abstractions, a Directory object which allows
manipulating files
in a
stale object, and 'snapshot' nature often confuses developers. Looking at
other API examples, Node.js's FileSystem API purely works on path names and
it looks much simpler. http://nodejs.org/api/fs.html
OTOH one limitation I could think of in not having JS object is it'll
disallow a possible future
On Mon, Jul 15, 2013 at 11:02 PM, Kinuko Yasuda kin...@chromium.org wrote:
Glad to see this proposal has a new draft.
On Sat, Jul 13, 2013 at 9:31 AM, Jonas Sicking jo...@sicking.cc wrote:
Executive Summary (aka TL;DR):
Below is the mozilla proposal for a simplified filesystem API
On Tue, Jul 16, 2013 at 8:56 AM, Eric U er...@google.com wrote:
On Mon, Jul 15, 2013 at 5:58 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jul 15, 2013 at 4:47 PM, Eric U er...@google.com wrote:
What's the purpose of DestinationDict? It seems redundant.
There's basically three potential
Sicking jo...@sicking.cc wrote:
Executive Summary (aka TL;DR):
Below is the mozilla proposal for a simplified filesystem API. It
contains two new abstractions, a Directory object which allows
manipulating files and directories within it, and a FileHandle object
which allows holding
Having the full path within the filesystem removes some of the
security benefit of not allowing .., doesn't it?
There's no problem if it's just an implementation detail.
Conversely, is the
path useful if you can't use it to manipulate anything above the
current dir in the tree?
It's useful
Hi,
On 2013-07-13 02:31, Jonas Sicking wrote:
[...]
interface FileHandle
{
readonly attribute FileOpenMode mode;
readonly attribute boolean active;
attribute long long? location;
location seems to be a bad name. It might be confused with location
in the filesystem. Why not use offset
of the Directory
interface. Though in that case not exposing open* at all and instead
relying on get() would probably work.
* A main reason we're considering exposing a filesystem API at all is
it's a familiar concept to authors. And most filesystem APIs have
openRead and openWrite (and posix has openAppend
reason we're considering exposing a filesystem API at all is
it's a familiar concept to authors. And most filesystem APIs have
openRead and openWrite (and posix has openAppend).
/ Jonas
On Mon, Jul 15, 2013 at 2:42 PM, Eric U er...@google.com wrote:
75% bikeshedding, 25% lessons learned:
It seems inconsistent to have the API for recursion done differently
in two different parts of the API: you've got two functions for
enumerate/enumerateDeep but remove takes a parameter to
On Mon, Jul 15, 2013 at 4:47 PM, Eric U er...@google.com wrote:
What's the purpose of DestinationDict? It seems redundant.
There's basically three potential ways to specify a copy/move destination:
Specify a new name within the current directory.
Specify a new directory but keep the current
files/directory a directory contains. Would be 0 for a
// file. This could also be .isEmpty(). But that might be
// mis-interpreted for files.
};
Thanks,
--
Mounir
On 12/07/13 17:31, Jonas Sicking wrote:
Hi All,
Yesterday a few of us at mozilla went through the FileSystem API
proposal we
On Sat, Jul 13, 2013 at 1:27 AM, David Rajchenbach-Teller
dtel...@mozilla.com wrote:
Why both createFile, open{Read, Write, Append} and get? Is it to avoid a
signature with dependent types?
I think you are asking why have createFile when it can be implemented
using openWrite or openAppend
Hi there!
A new file system API with a lot of promise :-)
On Sat, Jul 13, 2013 at 2:31 AM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Yesterday a few of us at mozilla went through the FileSystem API
proposal we previously sent [1] and tightened it up.
Executive Summary (aka TL;DR
the FileSystem API
proposal we previously sent [1] and tightened it up.
Executive Summary (aka TL;DR):
Below is the mozilla proposal for a simplified filesystem API. It
contains two new abstractions, a Directory object which allows
manipulating files and directories within it, and a FileHandle object
Why both createFile, open{Read, Write, Append} and get? Is it to avoid a
signature with dependent types?
Cheers,
David
On 7/13/13 2:31 AM, Jonas Sicking wrote:
PromiseFile createFile(DOMString path, MakeFileOptions options);
PromiseDirectory createDirectory(DOMString path);
Hi All,
Yesterday a few of us at mozilla went through the FileSystem API
proposal we previously sent [1] and tightened it up.
Executive Summary (aka TL;DR):
Below is the mozilla proposal for a simplified filesystem API. It
contains two new abstractions, a Directory object which allows
by files in
IndexedDB.
This new proposal is heavily based on Apple's minimal filesystem API
proposal [1], on Mozilla's DeviceStorage API 2 [2] and on Mozilla's current
FileHandle API [3]. It is only designed for the use case of sandboxed local
file storage.
In Firefox, the FileHandle API provides
Is there a long term plan for transferring access to Files from the FileSystem?
Currently, we can using FileEntry.file semantics then post the resulting Blob
to another frame. From that point, the receiver can create a Blob URL. I'm
concerned about all the extra work with Blobs which may get
On Tue, Aug 14, 2012 at 4:51 PM, Charles Pritchard ch...@jumis.com wrote:
Is there a long term plan for transferring access to Files from the
FileSystem?
Currently, we can using FileEntry.file semantics then post the resulting
Blob to another frame. From that point, the receiver can create a
On Tue, Feb 28, 2012 at 1:52 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Feb 28, 2012 at 10:47 AM, Kinuko Yasuda kin...@chromium.org wrote:
Hi,
While looking at the FileSystem API draft I noticed that we only expose
'modificationTime' in 'Metadata' object. Since FileEntry itself
Hi,
While looking at the FileSystem API draft I noticed that we only expose
'modificationTime' in 'Metadata' object. Since FileEntry itself doesn't
have 'size' field unlike File object maybe it's reasonable to add 'size'
field to Metadata?
http://www.w3.org/TR/file-system-api/#the-metadata
On Tue, Feb 28, 2012 at 10:47 AM, Kinuko Yasuda kin...@chromium.org wrote:
Hi,
While looking at the FileSystem API draft I noticed that we only expose
'modificationTime' in 'Metadata' object. Since FileEntry itself doesn't
have 'size' field unlike File object maybe it's reasonable to add
On Feb 28, 2012, at 1:52 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Feb 28, 2012 at 10:47 AM, Kinuko Yasuda kin...@chromium.org wrote:
Hi,
While looking at the FileSystem API draft I noticed that we only expose
'modificationTime' in 'Metadata' object. Since FileEntry itself
Hello,
http://www.w3.org/TR/file-system-api/#the-flags-interface
If you look at the description of exclusive flag (4.2.1), the
description states no exception, but the example (4.2.2) uses
exception to determine whether file already existed.
So the question is, what is wrong: the description
The exception is thrown by getFile on DirectoryEntrySync, not by the
Flags constructor; both the example and the flags interface are
correct.
On Sat, Oct 8, 2011 at 11:54 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
Hello,
http://www.w3.org/TR/file-system-api/#the-flags-interface
On Fri, Apr 15, 2011 at 4:01 PM, Arun Ranganathan a...@mozilla.com wrote:
On 4/15/11 6:29 PM, Aryeh Gregor wrote:
On Wed, Apr 13, 2011 at 4:35 PM, Robert Gindargi...@chromium.org wrote:
* The FileError object is a bit awkward to work with. I found that I
frequently had every reason to
On Mon, Apr 18, 2011 at 5:28 PM, Eric Uhrhane er...@google.com wrote:
On Fri, Apr 15, 2011 at 4:01 PM, Arun Ranganathan a...@mozilla.com wrote:
On 4/15/11 6:29 PM, Aryeh Gregor wrote:
On Wed, Apr 13, 2011 at 4:35 PM, Robert Gindargi...@chromium.org wrote:
* The FileError object is a bit
Hello public-webapps,
I've spent a bit of time with the filesystem API recently, building out a
set of common file dialogs (open, save-as, etc) for ChromeOS. We have
a private API call to get access to a special filesystem that contains the
user's downloads folder and the mounted external
Robert:
First of all, thanks for the feedback.
On Wed, Apr 13, 2011 at 1:35 PM, Robert Ginda rgi...@chromium.org wrote:
Hello public-webapps,
I've spent a bit of time with the filesystem API recently, building out a
set of common file dialogs (open, save-as, etc) for ChromeOS. We have
of time with the filesystem API recently, building out a
set of common file dialogs (open, save-as, etc) for ChromeOS. We have
a private API call to get access to a special filesystem that contains the
user's downloads folder and the mounted external storage, but beyond
that the dialogs use
On Wed, Apr 13, 2011 at 4:35 PM, Robert Ginda rgi...@chromium.org wrote:
* The FileError object is a bit awkward to work with. I found that I
frequently had every reason to expect my calls to succeed (because
they were a follow-on to something that already succeeded), but I
wanted to log the
On 4/15/11 6:29 PM, Aryeh Gregor wrote:
On Wed, Apr 13, 2011 at 4:35 PM, Robert Gindargi...@chromium.org wrote:
* The FileError object is a bit awkward to work with. I found that I
frequently had every reason to expect my calls to succeed (because
they were a follow-on to something that
On Mon, Feb 28, 2011 at 4:59 PM, Charles Pritchard ch...@jumis.com wrote:
On 2/28/2011 4:10 PM, Eric Uhrhane wrote:
On Mon, Feb 28, 2011 at 2:54 PM, Charles Pritchardch...@jumis.com
wrote:
I'd like some clarification on the intent of the FileSystem API:
requestFileSystem permanent
On Mon, Feb 28, 2011 at 6:21 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Feb 28, 2011 at 7:41 PM, Eric Uhrhane er...@google.com wrote:
Sorry--I meant to push this over to public-webapps, as Ian suggested.
[+cc public-webapps, whatwg-BCC]
Currently (reviewing for context), the spec tries
On Tue, Mar 1, 2011 at 1:13 PM, Eric Uhrhane er...@google.com wrote:
What would you suggest for limitations? If we're requiring
virtualization, it seems to me that we could be quite liberal.
I'd suggest only the restrictions that are required for the API: no
, ., .., and no filenames
On Tue, Mar 1, 2011 at 11:37 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Mar 1, 2011 at 1:13 PM, Eric Uhrhane er...@google.com wrote:
What would you suggest for limitations? If we're requiring
virtualization, it seems to me that we could be quite liberal.
I'd suggest only the
On 2/28/2011 3:50 PM, Ian Hickson wrote:
On Mon, 28 Feb 2011, Charles Pritchard wrote:
I'd like some clarification on the intent of the FileSystem API:
requestFileSystem permanent, getDirectory and getFile.
Are they intended to directly pass through to the host operating system
On Mon, Feb 28, 2011 at 3:50 PM, Charles Pritchard ch...@jumis.com wrote:
Are there any plans of reviewing/visiting efficient File/Blob support in
indexeddb?
Support for File and Blob is technically in the spec already, though I
don't think any implementations support it.
The more
of the FileSystem API:
requestFileSystem permanent, getDirectory and getFile.
The FileSystem API has several goals. Some of them are targeted by
the current spec, and some have been discussed, but put off until
later. We didn't want to take on too much in a single pass [hence the
three layers
On Mon, Feb 28, 2011 at 7:41 PM, Eric Uhrhane er...@google.com wrote:
Sorry--I meant to push this over to public-webapps, as Ian suggested.
[+cc public-webapps, whatwg-BCC]
Currently (reviewing for context), the spec tries to reach filename
consistency (only allowing filenames to be used
On Mon, Nov 29, 2010 at 11:45 AM, Joran Greef jo...@ronomon.com wrote:
I have some questions regarding the FileSystem API:
1. It would be great to be able to let the user choose where they want their
sandboxed directory located for the web app, i.e. on the desktop for quick
access. That way
2010/9/16 Eric Uhrhane er...@google.com:
How about this?
For a move/copy of a file on top of existing file, or a directory on
top of an existing empty directory, you get an automatic overwrite.
A move/copy of a file on top of an existing directory, or of a
directory on top of an existing
How about this?
For a move/copy of a file on top of existing file, or a directory on
top of an existing empty directory, you get an automatic overwrite.
A move/copy of a file on top of an existing directory, or of a
directory on top of an existing file, will always fail.
A move/copy of a file or
2010/9/16 Kinuko Yasuda kin...@chromium.org:
On Thu, Sep 16, 2010 at 2:50 PM, Eric Uhrhane er...@google.com wrote:
How about this?
For a move/copy of a file on top of existing file, or a directory on
top of an existing empty directory, you get an automatic overwrite.
A move/copy of a file on
On Thu, Sep 16, 2010 at 4:00 PM, Eric Uhrhane er...@google.com wrote:
2010/9/16 Kinuko Yasuda kin...@chromium.org:
On Thu, Sep 16, 2010 at 2:50 PM, Eric Uhrhane er...@google.com wrote:
How about this?
For a move/copy of a file on top of existing file, or a directory on
top of an existing
On Thu, Sep 9, 2010 at 12:12 AM, Kinuko Yasuda kin...@chromium.org wrote:
On Tue, Sep 7, 2010 at 6:12 PM, Eric Uhrhane er...@google.com wrote:
On Mon, Aug 30, 2010 at 9:27 PM, Kinuko Yasuda kin...@chromium.org
wrote:
Hi,
I have a question about Entry.moveTo/copyTo behavior defined in
I think recursive copy/remove is a very valid use case. As for overwrite, is
a flag necessary? On most OSes you already get overwrite as the default
behaviour (at least from APIs, many interactive UAs such as Explorer on
windows will prompt), is there a compelling argument why it should be
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 Mon, Aug 30, 2010 at 9:27 PM, Kinuko Yasuda kin...@chromium.org wrote:
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
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,
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
1 - 100 of 107 matches
Mail list logo