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
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 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
On Nov 6, 2013 3:50 AM, Jonas Sicking jo...@sicking.cc wrote:
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 store then
duplicate data would automatically be stored only once without any
security
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
That's very interesting and useful, but I don't think it fits the same use
case I was talking about. I want the ability to create some object that
exports an URL that I can put in an iframe. Then all requests from that
iframe for resources will dynamically call my javascript code. I could
There are multiple interesting ideas being discussed
1. Mapping files to persistent URLs.
2. Sharing persistent URLs between different origins.
3. Using the ServiceWorker [1] to redirect URL requests (and possibly
manage it's own cache / files)
4. De-duping file copies using a Git like scheme.
On Wed, Oct 30, 2013 at 7:19 PM, pira...@gmail.com pira...@gmail.comwrote:
What you are asking for could be fixed with redirects, that it's the
HTTP equivalent of filesystems symbolic links :-)
Is your suggestion that Google consolidate all its domains into one?
These are widely separated
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,
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 is
And here's an example:
// Copy the 1th byte of file1.bin to file2.bin
navigator.getFilesystem().then(function(root) {
return root.openWrite([file1.bin, file2.bin]);
}).then(function(handles) {
return handles[0].read(1);
}).then(function(buffer) {
return handles[1].write(buffer);
});
On
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
On Tue, Jul 16, 2013 at 11:29 AM, Mounir Lamouri mou...@lamouri.fr wrote:
Hi,
I am not a big fan of the Directory approach of this proposal. It puts
the API between a high level, object oriented API and a low level API.
It is unfortunately not really high level because you have to use the
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. It
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
On Tue, Jul 16, 2013 at 8:53 AM, Eric U er...@google.com wrote:
On Tue, Jul 16, 2013 at 12:32 AM, Jonas Sicking jo...@sicking.cc wrote:
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
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
On Mon, Jul 15, 2013 at 12:18 AM, Janusz Majnert j.majn...@samsung.com wrote:
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
15 lip 2013 10:47, Jonas Sicking jo...@sicking.cc napisał(a):
On Mon, Jul 15, 2013 at 12:18 AM, Janusz Majnert j.majn...@samsung.com
wrote:
Hi,
On 2013-07-13 02:31, Jonas Sicking wrote:
[...]
interface FileHandle
{
readonly attribute FileOpenMode mode;
readonly
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
Hi,
I am not a big fan of the Directory approach of this proposal. It puts
the API between a high level, object oriented API and a low level API.
It is unfortunately not really high level because you have to use the
Directory for most operations and the File objects can't be subject to
any
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):
On Sat, Jul 13, 2013 at 2:37 AM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
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
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
45 matches
Mail list logo
