Prototype of Files service.

services/file_manager/directory.mojom

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+module mojo.files;

[sky, 2015/02/06 15:54:46]

nit: I would have expected files to match your directory name. Maybe you should
rename one to match?

[viettrungluu, 2015/02/06 16:57:36]

It's extremely natural for there to be other implementors of File and Directory;
"file manager" just happens to be one of them. Possibly FileManager should not
be in the "files" namespace/module though. Possibly we should also split this
directory into two (file_manager and files -- the latter might also contain
client libraries and such).

+
+import "services/file_manager/file.mojom";
+import "services/file_manager/types.mojom";
+
+// TODO(vtl): paths may be relative; should they allowed to be absolute?
+// (currently not)
+
+interface Directory {
+  // Operations about "this" |Directory|:
+
+  Read() => (Error error, array<FileInformation>? directory_contents);

[jamesr, 2015/02/06 05:15:43]

in types.mojom FileInformation appears to only have size and FileTimes.  did you
mean to return array of |DirectoryEntry|s here?

[viettrungluu, 2015/02/06 06:20:41]

Oops, yes.

+  Change(string path) => (Error error);

[jamesr, 2015/02/06 05:15:43]

what does 'Change' do? does it modify what this |Directory| object points to?
how's it different from OpenDirectory().. ?

[viettrungluu, 2015/02/06 06:20:41]

Yes (i.e., it's chdir). I thought it was confusing too. Maybe I should call it
ChangeDirectory.
OpenDirectory gives you a new Directory.

[sky, 2015/02/06 15:54:46]

Seems less confusing to me if a directory only ever represents one path and
can't be changed. Is there a reason this needed instead of forcing callers to
use OpenDirectory?

[viettrungluu, 2015/02/06 17:01:23]

The idea was to make it easy to implement chdir() and notions like CWD for an
app, but you might right....

+
+  // Operations *in* "this" |Directory|:
+
+  OpenFile(string path, File& file, uint32 access_flags, uint32 open_flags)

[jamesr, 2015/02/06 05:15:43]

if you want to model accessing existing filesystems then |string| as a type
won't work since many filesystems support components that aren't in unicode.  if
we want to say that this is only for manipulating filesystems created with this
API or only for "sane" filesystems then we can stick with string

[viettrungluu, 2015/02/06 06:20:41]

For the purposes of Mojo apps, the latter seems better. Otherwise it's very hard
for apps. (I'm sure we "incorrectly" -- though what's the alternative? -- assume
that filenames are Unicode in many places.)

Existing filesystems are a mess (arbitrary byte strings, minus / and \0, being
the Unix-y thing; various other filesystems having explicit or implicit
character encodings; NTFS is arbitrary uint16_t strings, minus 0) ... and not
really being able to display filenames is no good.

+      => (Error error);
+  OpenDirectory(string path, Directory& directory) => (Error error);

[jamesr, 2015/02/06 05:15:43]

is |path| only relative to this? can it contain multiple components, or can you
only traverse one segment at a time? is there '..' in this?

[viettrungluu, 2015/02/06 06:20:41]

I imagine that it should be allowed to contain multiple components and .. should
be allowed. (Possibly it should also allow "absolute" paths, for some meaning of
"absolute" too.)

Some "chroot"-like facility, taking a Directory and declaring it the root for
all subsequent operations originating from that Directory (including other
Directory's opened from it, etc.) and preventing escape, seems like it would be
useful. (See my TODO below about "make root".)

+
+  Rename(string path, string new_path) => (Error error);

[sky, 2015/02/06 15:54:45]

Raw strings for paths is always error prone. Maybe it should be a struct with
the array of path elements? Or maybe this is better served by a client library
on top?

[viettrungluu, 2015/02/06 16:57:36]

I could go either way on this, though the reality is that real-life OS APIs take
single strings. (If I were king, they'd all take arrays of components, and you
might also allow /'s in components.) Another argument for strings is that paths
are passed in a lot of existing code as strings, including in mixed contexts
where the strings may not always be paths (e.g., argv).

Either way, I imagine there being various client libraries. (Note that a
particularly important client library would be a <stdio.h>-type library[*],
which would take strings for paths.)

[*] Of course, in a (P)NaCl app, such a client library would be *the*
implementation of <stdio.h>.

+
+  // TODO(vtl): mkdir
+  // TODO(vtl): rm/rmdir
+  // TODO(vtl): directory "streaming"?

[Aaron Boodman, 2015/02/06 04:41:57]

Yeah, seems like for large directories, returning everything as an array would
not be great.

+  // TODO(vtl): "make root" (i.e., prevent cd-ing, etc., to parent); note that
+  // this would require a much more complicated implementation (e.g., it needs
+  // to be "inherited" by OpenDirectory(), and the enforcement needs to be valid
+  // even if the opened directory is subsequently moved -- e.g., closer to the
+  // "root")
+};