Prototype of Files service.

services/file_manager/file.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.
+
+//FIXME FIXME FIXME: notes to self:
+//  - file offsets, file positions, and file sizes are int64 (though positions
+//    and sizes must always be non-negative)
+//  - buffer size parameters (for read/write) are uint32
+//  - timestamps are int64, milliseconds since Unix epoch (i.e., dubious)
+
+module mojo.files;
+
+import "services/file_manager/types.mojom";
+
+interface File {
+  Close() => (Error err);
+
+  Read(uint32 num_bytes_to_read, int64 offset, Whence whence)
+      => (Error error, array<uint8>? bytes_read);
+  Write(array<uint8> bytes_to_write, int64 offset, Whence whence)
+      => (Error error, uint32 num_bytes_written);
+
+  ReadStream(handle<data_pipe_producer> source, int64 offset, Whence whence)

[qsr, 2015/02/06 10:54:55]

When does those returns in a non error case? When the pipe is closed?

Do we want a size? I might not want to read the full file.

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

Hmmm, that's a good question.

I was imagining that it'd return as soon as reading "started" (for some weak
definition of "start"), but maybe that's not right.

(A usage pattern I was imagining was that someone might want to call this
"synchronously", end up with a valid data pipe to read from on success. Then
they might "synchronously" loop and consume from that data pipe.)
That's a good idea.

+      => (Error error);
+  WriteStream(handle<data_pipe_consumer> sink, int64 offset, Whence whence)
+      => (Error error);
+
+  Tell() => (Error error, int64 position);
+  Seek(int64 offset, Whence whence) => (Error error, int64 position);
+
+  Stat() => (Error error, FileInformation? file_information);
+  Truncate(int64 size) => (Error error);
+  // TODO(vtl): null |times| means "now" (for both atime and mtime).
+  Touch(FileTimes? times) => (Error error);
+
+  // TODO(vtl): |Dup()| shares the same file description (i.e., mode and
+  // position).
+  Dup(File& file) => (Error error);
+  // TODO(vtl): What are the rules for reopening (w.r.t. changing mode/flags).
+  // E.g., obviously can go from "read-write" to "read", but reverse? (probably
+  // not), can remove "append"? (probably not?). Do we allow "truncate"?
+  Reopen(File& file, uint32 access_flags, uint32 open_flags)
+      => (Error error);

[abarth-chromium, 2015/02/06 04:38:35]

I imagine we'll want to be able to pass Files to other apps with the idea that
they'll be limited in their access to that file.  Going from "read-only" to
"read-write" seems a bit scary in that situation.

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

Right. The more confusing ones are "append", etc.

(The reason I want "reopen" in addition to "dup" is that "dup" shares the
position in the file (the "file description", in POSIX parlance), which is
pretty inconvenient for passing Files to other apps. Maybe I should just combine
them and distinguish them using a flag though.)

+
+  // TODO(vtl): probably should have access flags (but also exec?); how do these
+  // relate to access mode?
+  AsBuffer() => (Error error, handle<shared_buffer>? buffer);
+
+  // TODO(vtl): Add a "watch"?
+};