RE: flush() | was Re: FileSystem API Comments

2014-11-06 Thread Ali Alabbas
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

flush() | was Re: FileSystem API Comments

2014-10-31 Thread Arun Ranganathan
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

RE: FileSystem API Comments

2014-10-22 Thread Jonathan Bond-Caron
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

Re: FileSystem API Comments

2014-10-22 Thread David Rajchenbach-Teller
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

Re: FileSystem API Comments

2014-10-22 Thread chaals
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

Re: FileSystem API Comments

2014-10-22 Thread Arun Ranganathan
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

FileSystem API Comments

2014-10-21 Thread Ali Alabbas
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

Re: FileSystem API Comments

2014-10-21 Thread Arthur Barstow
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

FileSystem API behavior of seek function

2014-01-18 Thread Kyle Graehl
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

Re: Polished FileSystem API proposal

2013-11-06 Thread Tim Caswell
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

Re: Polished FileSystem API proposal

2013-11-06 Thread Jonas Sicking
. (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

Re: Polished FileSystem API proposal

2013-11-06 Thread Tim Caswell
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

Re: Polished FileSystem API proposal

2013-11-06 Thread pira...@gmail.com
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

Re: Polished FileSystem API proposal

2013-11-06 Thread Tim Caswell
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

Re: Polished FileSystem API proposal

2013-11-06 Thread pira...@gmail.com
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

Re: Polished FileSystem API proposal

2013-11-06 Thread Brian Stell
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

Re: Polished FileSystem API proposal

2013-11-05 Thread Brian Stell
-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

Re: Polished FileSystem API proposal

2013-11-05 Thread Anne van Kesteren
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

Re: Polished FileSystem API proposal

2013-11-05 Thread Brian Stell
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

Re: Polished FileSystem API proposal

2013-10-30 Thread pira...@gmail.com
+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

Re: Polished FileSystem API proposal

2013-10-30 Thread Brian Stell
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

Re: Polished FileSystem API proposal

2013-10-30 Thread pira...@gmail.com
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

Re: Polished FileSystem API proposal

2013-10-30 Thread pira...@gmail.com
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

Re: Polished FileSystem API proposal

2013-10-29 Thread Brian Stell
I meant eg, V1/dir1/file1, V2/dir1/file1.

Re: Polished FileSystem API proposal

2013-10-29 Thread Brendan Eich
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.

Re: Polished FileSystem API proposal

2013-10-28 Thread Brian Stell
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,

Re: FileSystem API

2013-08-26 Thread Arthur Barstow
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

Re: FileSystem API

2013-08-26 Thread Arun Ranganathan
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

Re: FileSystem API

2013-08-26 Thread Jonas Sicking
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

FileSystem API

2013-08-19 Thread Arun Ranganathan
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

Re: FileSystem API

2013-08-19 Thread Eric U
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

Re: FileSystem API

2013-08-19 Thread Jonas Sicking
: 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

Re: Polished FileSystem API proposal

2013-07-23 Thread pira...@gmail.com
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,

Re: Polished FileSystem API proposal

2013-07-22 Thread Jan Varga
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

Re: Polished FileSystem API proposal

2013-07-22 Thread Jan Varga
, 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

Re: Polished FileSystem API proposal

2013-07-22 Thread Jonas Sicking
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

Re: Polished FileSystem API proposal

2013-07-22 Thread 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 notifications will automatically be noticed and

Re: Polished FileSystem API proposal

2013-07-22 Thread Janusz Majnert
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

Re: Polished FileSystem API proposal

2013-07-22 Thread Kinuko Yasuda
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

Re: Polished FileSystem API proposal

2013-07-22 Thread Jonas Sicking
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

Re: Polished FileSystem API proposal

2013-07-18 Thread Mounir Lamouri
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

Re: Polished FileSystem API proposal

2013-07-18 Thread Anne van Kesteren
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

Re: Polished FileSystem API proposal

2013-07-18 Thread Jonas Sicking
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

Re: Polished FileSystem API proposal

2013-07-16 Thread Kinuko Yasuda
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

Re: Polished FileSystem API proposal

2013-07-16 Thread Kinuko Yasuda
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

Re: Polished FileSystem API proposal

2013-07-16 Thread Jonas Sicking
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

Re: Polished FileSystem API proposal

2013-07-16 Thread Jonas Sicking
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

Re: Polished FileSystem API proposal

2013-07-16 Thread Jonas Sicking
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

Re: Polished FileSystem API proposal

2013-07-16 Thread pira...@gmail.com
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

Re: Polished FileSystem API proposal

2013-07-15 Thread Janusz Majnert
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

Re: Polished FileSystem API proposal

2013-07-15 Thread Jonas Sicking
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

Re: Polished FileSystem API proposal

2013-07-15 Thread Janusz Majnert
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

Re: Polished FileSystem API proposal

2013-07-15 Thread Jonas Sicking
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

Re: Polished FileSystem API proposal

2013-07-15 Thread Jonas Sicking
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

Re: Polished FileSystem API proposal

2013-07-15 Thread Mounir Lamouri
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

Re: Polished FileSystem API proposal

2013-07-13 Thread Jonas Sicking
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

Re: Polished FileSystem API proposal

2013-07-13 Thread Kenneth Rohde Christiansen
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

Re: Polished FileSystem API proposal

2013-07-13 Thread Jonas Sicking
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

Re: Polished FileSystem API proposal

2013-07-13 Thread David Rajchenbach-Teller
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);

Polished FileSystem API proposal

2013-07-12 Thread Jonas Sicking
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

Proposal for a filesystem API

2013-04-25 Thread Jan Varga
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

FileSystem API: Cross origin sharing

2012-08-14 Thread Charles Pritchard
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

Re: FileSystem API: Cross origin sharing

2012-08-14 Thread Glenn Maynard
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

Re: FileSystem API: Adding file size field to Metadata?

2012-02-29 Thread Eric Uhrhane
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

FileSystem API: Adding file size field to Metadata?

2012-02-28 Thread Kinuko Yasuda
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

Re: FileSystem API: Adding file size field to Metadata?

2012-02-28 Thread Darin Fisher
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

Re: FileSystem API: Adding file size field to Metadata?

2012-02-28 Thread Charles Pritchard
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

FileSystem API - The Flags interface

2011-10-09 Thread Bronislav Klučka
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

Re: FileSystem API - The Flags interface

2011-10-09 Thread Eric U
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

Re: HTML5 Filesystem API feedback

2011-04-18 Thread Eric Uhrhane
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

Re: HTML5 Filesystem API feedback

2011-04-18 Thread Robert Ginda
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

HTML5 Filesystem API feedback

2011-04-15 Thread Robert Ginda
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

Re: HTML5 Filesystem API feedback

2011-04-15 Thread Eric Uhrhane
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

Re: HTML5 Filesystem API feedback

2011-04-15 Thread Robert Ginda
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

Re: HTML5 Filesystem API feedback

2011-04-15 Thread Aryeh Gregor
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

Re: HTML5 Filesystem API feedback

2011-04-15 Thread Arun Ranganathan
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

Re: [whatwg] Intent of the FileSystem API

2011-03-01 Thread Eric Uhrhane
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

Re: [whatwg] Intent of the FileSystem API

2011-03-01 Thread Eric Uhrhane
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

Re: [whatwg] Intent of the FileSystem API

2011-03-01 Thread Glenn Maynard
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

Re: [whatwg] Intent of the FileSystem API

2011-03-01 Thread Eric Uhrhane
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

Re: [whatwg] Intent of the FileSystem API

2011-02-28 Thread Charles Pritchard
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

Re: [whatwg] Intent of the FileSystem API

2011-02-28 Thread Jonas Sicking
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

Re: [whatwg] Intent of the FileSystem API

2011-02-28 Thread Eric Uhrhane
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

Re: [whatwg] Intent of the FileSystem API

2011-02-28 Thread Glenn Maynard
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

Re: FileSystem API: Avoiding Upload Forms And Temporary Downloads

2010-11-30 Thread Eric Uhrhane
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

Re: FileSystem API - overwrite flag for copy/move?

2010-09-28 Thread Eric Uhrhane
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

Re: FileSystem API - overwrite flag for copy/move?

2010-09-16 Thread Eric Uhrhane
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

Re: FileSystem API - overwrite flag for copy/move?

2010-09-16 Thread Eric Uhrhane
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

Re: FileSystem API - overwrite flag for copy/move?

2010-09-16 Thread Kinuko Yasuda
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

Re: FileSystem API - overwrite flag for copy/move?

2010-09-09 Thread Kinuko Yasuda
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

Re: FileSystem API - overwrite flag for copy/move?

2010-09-09 Thread イアンフェッティ
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

Re: Flags for getFile/getDirectory (Re: New draft of FileSystem API posted)

2010-09-08 Thread Ian Hickson
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

Re: Flags for getFile/getDirectory (Re: New draft of FileSystem API posted)

2010-09-08 Thread Eric Uhrhane
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

Re: Flags for getFile/getDirectory (Re: New draft of FileSystem API posted)

2010-09-07 Thread Kinuko Yasuda
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

Re: Flags for getFile/getDirectory (Re: New draft of FileSystem API posted)

2010-09-07 Thread Eric Uhrhane
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

Re: FileSystem API - overwrite flag for copy/move?

2010-09-07 Thread Eric Uhrhane
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

Re: Flags for getFile/getDirectory (Re: New draft of FileSystem API posted)

2010-09-07 Thread Adam Barth
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 /

Re: Flags for getFile/getDirectory (Re: New draft of FileSystem API posted)

2010-09-07 Thread Ian Hickson
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

Re: Flags for getFile/getDirectory (Re: New draft of FileSystem API posted)

2010-09-07 Thread Darin Fisher
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

FileSystem API - overwrite flag for copy/move?

2010-08-30 Thread Kinuko Yasuda
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   2   >