[WIP] Provided file system from NACL.

ppapi/api/dev/ppb_filesystemprovider_dev.idl

+/* 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.
+ */
+
+/**
+ * This file defines the <code>PPB_FilesystemProvider</code> interface.
+ */
+
+label Chrome {
+  M40 = 0.1
+};
+
+enum PP_ProviderError_Dev {

[llandwerlin-old, 2015/06/03 11:15:54]

You should probably use the errors codes defined in pp_errors.idl.
And add new ones there is you need to.

+  PP_ProviderError_NONE,
+  PP_ProviderError_OK,
+  PP_ProviderError_FAILED,
+  PP_ProviderError_IN_USE,
+  PP_ProviderError_EXISTS,
+  PP_ProviderError_NOT_FOUND,
+  PP_ProviderError_ACCESS_DENIED,
+  PP_ProviderError_TOO_MANY_OPENED,
+  PP_ProviderError_NO_MEMORY,
+  PP_ProviderError_NO_SPACE,
+  PP_ProviderError_NOT_A_DIRECTORY,
+  PP_ProviderError_INVALID_OPERATION,
+  PP_ProviderError_SECURITY,
+  PP_ProviderError_ABORT,
+  PP_ProviderError_NOT_A_FILE,
+  PP_ProviderError_NOT_EMPTY,
+  PP_ProviderError_INVALID_URL,
+  PP_ProviderError_IO
+};
+
+enum PP_OperationType_Dev{
+  PP_OperationType_NONE,
+  PP_OperationType_UNMOUNT,
+  PP_OperationType_GETMETADATA,
+  PP_OperationType_READDIRECTORY,
+  PP_OperationType_OPENFILE,
+  PP_OperationType_CLOSEFILE,
+  PP_OperationType_READFILE,
+  PP_OperationType_CREATEDIRECTORY,
+  PP_OperationType_DELETEENTRY,
+  PP_OperationType_CREATEFILE,
+  PP_OperationType_COPYENTRY,
+  PP_OperationType_MOVEENTRY,
+  PP_OperationType_TRUNCATEENTRY,
+  PP_OperationType_WRITEFILE,
+  PP_OperationType_ABORT
+};
+
+enum PP_OpenFileMode_Dev {
+  PP_OpenFileMode_NONE,
+  PP_OpenFileMode_READ,
+  PP_OpenFileMode_WRITE
+};
+
+enum PP_ChangeType_Dev {
+  PP_ChangeType_NONE,
+  PP_ChangeType_CHANGED,
+  PP_ChangeType_DELETED
+};
+/**
+* Used by SendMetadataSuccessResponse and
+* SendReadDirectorySuccessResponse to describe an entry/entries.
+*/
+struct PP_EntryMetadata_Dev{
+  PP_Bool   is_directory;
+  char[128] name;
+  uint64_t  size;
+  char[64]  modification_time;
+  char[128] mime_type;
+  char[512] thumbnail;
+};
+
+struct PP_FilesystemRequestUnmount{
+};
+
+struct PP_FilesystemRequestMetadata{
+  char[256] entry_path;

[llandwerlin-old, 2015/06/03 11:15:54]

I'm sorry, when we discussed this last time, I understood that the strings in
these structures would be names, not paths. Names are limited (256 characters on
unix systems), but paths can be indefinitely long. Again, I'm sorry I misled you
there.

I guess you could keep the structures mostly as they are and just replace the
char[256] by mem_t (you might be able to keep char[] in PP_EntryMetadata_Dev but
only if this is specified somewhere in the filesystem provider documentation).
Then instead of passing a 

[out] PP_FilesystemRequest request

argument to GetNextRequest() you could pass a

[in] PP_ArrayOutput output

which would be used by the proxy to allocate the right size for structure +
strings. In memory the layout would look something like this :

[ sizeof(PP_FilesystemRequestValue) | size(string1) | string(string2) | ... ]
(for now 2 is the maximum number of strings you have to deal with).

For example in the case of PP_FilesystemRequestCopyEntry this would be the
sizeof PP_FilesystemRequestValue + the size of source_path + size of
target_path.

PP_FilesystemRequestCopyEntry would look like this :

struct PP_FilesystemRequestCopyEntry {
  mem_t source_path;
  mem_t target_path; 
};

Where source_path points at sizeof(PP_FilesystemRequestValue) and target_path
points at sizeof(PP_FilesystemRequestValue) + sizeof(source_path).

+  PP_Bool thumbnail;
+};
+
+struct PP_FilesystemRequestReadDirectory{
+  char[256] directory_path;
+};
+
+struct PP_FilesystemRequestOpenFile{
+  char[256] file_path;
+  PP_OpenFileMode_Dev mode;
+};
+
+struct PP_FilesystemRequestCloseFile{
+  int32_t open_request_id;
+};
+
+struct PP_FilesystemRequestReadFile{
+  int32_t open_request_id;
+  uint64_t offset;
+  uint64_t length;
+};
+
+struct PP_FilesystemRequestCreateDirectory{
+  char[256] directory_path;
+  PP_Bool recursive;
+};
+
+struct PP_FilesystemRequestDeleteEntry{
+  char[256] entry_path;
+  PP_Bool recursive;
+};
+
+struct PP_FilesystemRequestCreateFile{
+  char[256] file_path;
+};
+
+struct PP_FilesystemRequestCopyEntry{
+  char[256] source_path;
+  char[256] target_path;
+};
+
+struct PP_FilesystemRequestMoveEntry{
+  char[256] source_path;
+  char[256] target_path;
+};
+
+struct PP_FilesystemRequestTruncate{
+  char[256] file_path;
+  int32_t length;
+};
+
+struct PP_FilesystemRequestWrite{
+  int32_t open_request_id;
+  uint64_t offset;
+  uint64_t data_size;
+  mem_t data;
+};
+
+struct PP_FilesystemRequestAbort{
+  int32_t operation_request_id;
+};
+/**
+* The request format
+*/
+[union] struct PP_FilesystemRequestValue {
+  PP_FilesystemRequestUnmount  as_unmount;
+  PP_FilesystemRequestMetadata as_metadata;
+  PP_FilesystemRequestReadDirectory as_read_directory;
+  PP_FilesystemRequestOpenFile as_open_file;
+  PP_FilesystemRequestCloseFile as_close_file;
+  PP_FilesystemRequestReadFile as_read_file;
+  PP_FilesystemRequestCreateDirectory as_create_directory;
+  PP_FilesystemRequestDeleteEntry as_delete_entry;
+  PP_FilesystemRequestCreateFile as_create_file;
+  PP_FilesystemRequestCopyEntry as_copy_entry;
+  PP_FilesystemRequestMoveEntry as_move_entry;
+  PP_FilesystemRequestTruncate as_truncate;
+  PP_FilesystemRequestWrite as_write_file;
+  PP_FilesystemRequestAbort as_abort;
+};
+
+struct PP_FilesystemRequest{

[llandwerlin-old, 2015/06/03 11:15:54]

Why not having a PP_FilesystemResponse structure as well?
You could remove most of the Send* methods of the interface.

+  PP_OperationType_Dev operation_type;
+  int32_t request_id;
+  PP_FilesystemRequestValue value;
+};
+/**
+* File system provider interface.
+* Typical usage:
+* - Use Create() to create a new <code>PPB_FilesystemProvider_Dev resource
+* - Call Mount() to register the new filesystem with the browser
+*      This will create an entry in the file manager Chrome OS UI. The user
+*      can select among the listed filesystem and issue file system operations
+* - Call Unmount() to unregister the filesystem
+*      This will remove the entry from the file manager Chrome OS UI.
+* - Register callback for the <code>PP_FilesystemRequest</code> messages that
+*   are sent from the browser with <code>GetNextRequest</code>
+* - When a request is received and the processing results in a succcess:
+*     - call <code>SendSuccessResponse</code> for requests DIFFERENT from
+*           <code>PP_FilesystemRequestMetadata</code>,
+*           <code>PP_FilesystemRequestReadDirectory</code>,
+*           <code>PP_FilesystemRequestReadFile</code>
+*     - call <code>SendMetadataSuccessResponse</code> for
+*            <code>PP_FilesystemRequestMetadata</code> request
+*     - call <code>SendReadFileSuccessResponse</code> for
+*           <code>PP_FilesystemRequestReadFile</code> request
+*     - call <code>SendReadDirectorySuccessResponse</code> for
+*           <code>PP_FilesystemRequestReadDirectory</code> request
+* - When a request is received and the processing results in an error:
+*     - call <code>SendErrorResponse</code> for ALL requests
+* - If a PP_FilesystemRequestWrite is received a subsequent call to
+*   <code>FreeWriteRequestBuffer</code>
+*/
+
+interface PPB_FilesystemProvider_Dev {
+
+PP_Resource Create(
+    [in] PP_Instance instance );
+
+PP_Bool IsFilesystemProvider(
+    [in] PP_Resource resource );
+/**
+* Mount() registers the file system
+* @param[in] filesystem_id A <code>PP_VARTYPE_STRING</code>
+* @param[in] display_name A <code> PP_VARTYPE_STRING</code>
+* @param[in] writable A <code> PP_VARTYPE_BOOL </code>
+* @param[in] opened_files_limit A <code>int32_t</code>
+* @param[out] error A <PP_ProviderError_Dev</code>
+* @param[in] callback A <code>PP_CompletionCallback</code> called when
+* the operation completes asynchronously.
+*/
+int32_t Mount(
+    [in] PP_Resource filesystem_prov,
+    [in] PP_Var filesystem_id,
+    [in] PP_Var display_name,
+    [in] PP_Bool writable,
+    [in] int32_t opened_files_limit,
+    [out]PP_ProviderError_Dev error,
+    [in] PP_CompletionCallback callback  );
+/**
+* Unmount() unregister the file system
+* @param[in] filesystem_id A <code>PP_VARTYPE_STRING</code>
+* @param[out] error A <code>PP_ProviderError</code>
+* @param[in] callback <code>PP_CompletionCallback</code> called when the
+* operation completes asynchronously.
+*/
+int32_t Unmount(
+    [in] PP_Resource filesystem_prov,
+    [in] PP_Var filesystem_id,
+    [out]PP_ProviderError_Dev error,
+    [in] PP_CompletionCallback callback );
+
+/**
+* Most of the operation will rely on the bellow 2 function calls to
+* to report status to the browser.
+* SendSuccessResponse() sends acknowledges the successful completion of the
+* requested file system operation.
+* @param[in] operation_type A <code>PP_OperationType_Dev</code>
+* @param[in] request_id A <code>int32_t</code> the id of the request
+*/
+int32_t SendSuccessResponse(
+    [in] PP_Resource filesystem_prov,
+    [in] PP_OperationType_Dev operation_type,
+    [in] int32_t request_id );
+
+/**
+* SendErrorResponse() notifies the browser that the request failed.
+* @param[in] operationType A <code>PP_ProviderError</code>
+* @param[in] request_id A <code>int32_t</code>
+*/
+int32_t SendErrorResponse(
+    [in] PP_Resource filesystem_prov,
+    [in] PP_OperationType_Dev operation_type,
+    [in] PP_ProviderError_Dev error,
+    [in] int32_t request_id );
+
+/**
+* Special functions that don't follow the above template
+* for browser responses.
+* SendMetadataSuccessResponse() acknowledges the successful retrieval of the
+* metadata information
+* @param[in] metadata A <code>PP_EntryMetadata_Dev</code>
+* @param[in] request_id <code>int32_t</code>
+*/
+int32_t SendMetadataSuccessResponse(
+    [in] PP_Resource filesystem_prov,
+    [in] PP_EntryMetadata_Dev metadata,
+    [in] int32_t request_id );
+
+/**
+* SendReadDirectorySuccessResponse acknowledges the successful retrieval of
+* metadatas information for directories and files
+* @param[in] array_size A <code>uint32_t</code>
+* @param[in] entries several <code>PP_EntryMetadata_Dev</code>
+* @param[in] has_more A <code>PP_VARTYPE_BOOL</code>
+* @param[in] request_id A <code>int32_t</code>
+*/
+int32_t SendReadDirectorySuccessResponse(
+    [in] PP_Resource filesystem_prov,
+    [in] uint32_t array_size,
+    [in, size_is(array_size)] PP_EntryMetadata_Dev[] entries,
+    [in] PP_Bool has_more,
+    [in] int32_t request_id );
+/**
+* SendReadFileSuccessResponse() acknowledges the successful completion of a
+* read request.
+* @param[in] data_size A <code>uint32_t</code>
+* @param[in] data A pointer to the begining of the file chunk read from file
+* @param[in] has_more A <code>PP_VARTYPE_BOOL</code>
+* @param[in] request_id A <code>int32_t</code>
+*/
+int32_t SendReadFileSuccessResponse(
+    [in] PP_Resource filesystem_prov,
+    [in] uint32_t data_size,
+    [in, size_is(data_size)] mem_t data,

[llandwerlin-old, 2015/06/03 11:15:54]

It seems you have shared memory for data coming from the browser to the plugin.
But for some reason you don't apply this principle to sending data from the
plugin to the browser. Why not?

+    [in] PP_Bool has_more,
+    [in] int32_t request_id );
+/**
+* GetNextRequest() registers a callback for any pending requests.
+* @param[out] request A <code>PP_FilesystemRequest</code> this contains the
+* request for a file system operation
+* @param[in] callback A <code>PP_CompletionCallback</code> that is called when
+* a request becomes available.
+*/
+int32_t GetNextRequest(
+    [in]  PP_Resource filesystem_prov,
+    [out] PP_FilesystemRequest request,
+    [in]  PP_CompletionCallback callback);
+/**
+* FreeWriteRequestBuffer frees resource buffer. This MUST be called after the
+* request is processed
+* @param[in] buffer A pointer to the start of the file chunk in memory
+*/
+int32_t FreeWriteRequestBuffer(

[llandwerlin-old, 2015/06/03 11:15:55]

RecycleRequestBuffer() would be a more appropriate name.

+    [in] PP_Resource filesystem_prov,
+    [in] mem_t buffer);
+};
+