Declare providing extension capabilities in the manifest.

chrome/common/extensions/api/file_system_provider/file_system_provider_handler.h

Index: chrome/common/extensions/api/file_system_provider/file_system_provider_handler.h
diff --git a/chrome/common/extensions/api/file_system_provider/file_system_provider_handler.h b/chrome/common/extensions/api/file_system_provider/file_system_provider_handler.h
new file mode 100644
index 0000000000000000000000000000000000000000..25f2b4c625175a6a56b500c8a595d3ab7f852006
--- /dev/null
+++ b/chrome/common/extensions/api/file_system_provider/file_system_provider_handler.h
@@ -0,0 +1,59 @@
+// 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.
+
+#ifndef CHROME_COMMON_EXTENSIONS_API_FILE_SYSTEM_PROVIDER_FILE_SYSTEM_PROVIDER_HANDLER_H_
+#define CHROME_COMMON_EXTENSIONS_API_FILE_SYSTEM_PROVIDER_FILE_SYSTEM_PROVIDER_HANDLER_H_
+
+#include <string>
+#include <vector>
+
+#include "chrome/common/extensions/api/file_system_provider.h"
+#include "extensions/common/extension.h"
+#include "extensions/common/manifest_handler.h"
+
+namespace extensions {
+
+// Source of provider file systems.
+enum FileSystemProviderSource { SOURCE_FILE, SOURCE_NETWORK, SOURCE_DEVICE };
+
+// Represents capabilities of a file system provider.
+class FileSystemProviderCapabilities : public Extension::ManifestData {

[not at google - send to devlin, 2015/04/23 23:16:35]

Consider declaring this here:

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/common/exte...

that will
- let you automatically generate much of the code here (in the CC file at least)
- let you automatically generate docs
- easily update as you go
- maybe even let you reference the enum sources from the APIs directly, rather
than defining them yet-again?

[mtomasz, 2015/04/24 12:16:11]

I often feel reluctant to use generated types widely. I usually convert them to
manually written types as soon as possible. The reason is that the auto
generated classes are not very neat: not modifiable, in inconvenient namespaces,
often break style guides, and enums have some extra values like X_NONE, which
forces to handle them in each switch case (or use default: which disables
compile checks for unhandled values) even though the enum value is always
mandatory.

I'm not sure about moving "Capabilities" dictionary (aka file_system_provider
manifest section) from file_system_provider.idl to manifest_types.json, as we
want to generate the "Capabilities" documentation in File System Provider API
documentation page, instead of the manifest one. In the manifest one, we'd
simply like to mention that such section exists with a link to File System
Provider API documentation with more details. Similarly to File Browser Handler
API, see:

https://developer.chrome.com/extensions/manifest.

WDYT?

[not at google - send to devlin, 2015/04/24 16:18:32]

I agree. My other issue with using generated types directly is that they're
harder to find if you're browsing the documentation using grep; only codesearch
will find things properly.

You can still many of the benefits using the generate types, though; generating
the parsing logic (even if you just chuck that straight into a new struct),
compile safety now and as you change things, documentation generation, and
hopefully cross-referencing the shared data, like enums. I did something similar
for ExternallyConnectable; declared the type in the JSON file, parsed it, then
put it in a new struct that I defined in code.
Does this come back to the question about consistency within the API (reusing
the same structure), or consistency with the manifest style (underscores in
manifest, camelcase in API)? Either way, I think it's a good idea to declare the
type in file_system_provider.idl rather than manifest_types.json - and that
doesn't stop you from using it here in the same way. And like I said in the
other comment, my preference *is* for manifest consistency rather than API
consistency.

[mtomasz, 2015/04/24 17:12:10]

I may be missing sth here, but it's exactly what I'm doing here. I'm using
Capabilities dictionary from file_system_provider.idl to parse the manifest
"file_system_provider" section.
I think it's exactly what I'm doing.

+ public:
+  FileSystemProviderCapabilities();
+  FileSystemProviderCapabilities(bool configurable,
+                                 bool multiple_mounts,
+                                 FileSystemProviderSource source);
+  ~FileSystemProviderCapabilities() override;
+
+  // Returns an array of URL handlers |extension| has defined in its manifest.
+  static FileSystemProviderCapabilities Get(const Extension* extension);
+
+  bool configurable() const { return configurable_; }
+  bool multiple_mounts() const { return multiple_mounts_; }
+  FileSystemProviderSource source() const { return source_; }
+
+ private:
+  bool configurable_;
+  bool multiple_mounts_;
+  FileSystemProviderSource source_;
+};
+
+// Parses the "file_system_provider" manifest key.
+class FileSystemProviderHandler : public ManifestHandler {
+ public:
+  FileSystemProviderHandler();
+  ~FileSystemProviderHandler() override;
+
+  // ManifestHandler overrides.
+  bool Parse(Extension* extension, base::string16* error) override;
+
+ private:
+  const std::vector<std::string> Keys() const override;
+
+  DISALLOW_COPY_AND_ASSIGN(FileSystemProviderHandler);
+};
+
+}  // namespace extensions
+
+#endif  // CHROME_COMMON_EXTENSIONS_API_FILE_SYSTEM_PROVIDER_FILE_SYSTEM_PROVIDER_HANDLER_H_