Convert the utility process JSON parser into a Mojo service.

components/safe_json/safe_json_parser_mojo_impl.cc

Index: components/safe_json/safe_json_parser_mojo_impl.cc
diff --git a/components/safe_json/safe_json_parser_mojo_impl.cc b/components/safe_json/safe_json_parser_mojo_impl.cc
new file mode 100644
index 0000000000000000000000000000000000000000..931c5d07066f3a5e94965eb0d53ab6d200c843a7
--- /dev/null
+++ b/components/safe_json/safe_json_parser_mojo_impl.cc
@@ -0,0 +1,43 @@
+// Copyright 2016 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.
+
+#include "components/safe_json/safe_json_parser_mojo_impl.h"

[Bernhard Bauer, 2016/04/13 15:49:08]

Technically, we should split this up into a browser part and a utility part, no?
We got around that somewhat by having this in chrome/utility previously (which
admittedly was kind of wrong), but I would be a bit worried about just putting
utility and browser parts into the same directory now.

[Anand Mistry (off Chromium), 2016/04/14 00:59:49]

Well, the utility-side message filter was still in this directory (and the
wrapper was a layering quirk) so what I have now is no different than before.
Also, build rules keep the two sides separate.

This situation exists in quite a few places with Mojo and there isn't a great
solution for it yet. The only solid pattern we have so far is where the .mojom
files live (public/interfaces). One pattern is to have "client libraries"
(SafeJsonParserImpl in this case) in public/ or public/cpp/, but that isn't
followed in many places. If you have any ideas, I'd be happy to hear them.

Something else to consider is that in the mid-future, another change will likely
happen where the utility process is split into Mojo "apps" and the utility
process as a dumping ground goes away. This is longer term, but something to
keep in mind when considering layering and directory structure.

[Bernhard Bauer, 2016/04/14 14:11:38]

Sure, they get built as different targets, but there is nothing keeping the code
in this class from including e.g. content/public/browser/browser_thread.h.
Could we just move the _mojo_impl.* files into a utility/ subdirectory, and the
other files into a browser/ subdirectory? That would match the layout for other
components that are split across multiple processes.

[Anand Mistry (off Chromium), 2016/04/18 05:06:45]

I've made the change for this latest patchset. However, I think it's somewhat
invasive and not worth it. I'd prefer to revert the browser/ change and keep the
utility/ side since that's quite small and isolated.

[Bernhard Bauer, 2016/04/20 16:43:15]

OK, fair enough. It is a rather big change, and initially I didn't see that the
handler already is in the same directory as the browser side today, so this
isn't actually a regression. It might still be a good thing to do though (in a
follow up, not necessarily for you).

+
+#include <utility>
+
+#include "base/json/json_reader.h"
+#include "base/memory/scoped_ptr.h"
+#include "base/values.h"
+
+namespace safe_json {
+
+// static
+void SafeJsonParserMojoImpl::Create(
+    mojo::InterfaceRequest<mojom::SafeJsonParser> request) {
+  new SafeJsonParserMojoImpl(std::move(request));
+}
+
+SafeJsonParserMojoImpl::SafeJsonParserMojoImpl(
+    mojo::InterfaceRequest<mojom::SafeJsonParser> request)
+    : binding_(this, std::move(request)) {}
+
+SafeJsonParserMojoImpl::~SafeJsonParserMojoImpl() {
+}
+
+void SafeJsonParserMojoImpl::Parse(const mojo::String& json,
+                                   const ParseCallback& callback) {
+  int error_code;
+  std::string error;
+  scoped_ptr<base::Value> value = base::JSONReader::ReadAndReturnError(
+      json.get(), base::JSON_PARSE_RFC, &error_code, &error);
+  base::ListValue wrapper;
+  if (value) {
+    wrapper.Append(std::move(value));
+    callback.Run(wrapper, nullptr);
+  } else {
+    callback.Run(wrapper, error);
+  }
+}
+
+}  // namespace safe_json