Replace image_messages.h with Mojo service

content/browser/image_downloader/image_downloader_dispatcher.h

+// 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 CONTENT_BROWSER_IMAGE_DOWNLOADER_DISPATCHER_H_
+#define CONTENT_BROWSER_IMAGE_DOWNLOADER_DISPATCHER_H_
+
+#include "base/macros.h"
+#include "content/common/image_downloader/image_downloader.mojom.h"
+#include "content/public/browser/web_contents.h"
+
+class GURL;
+
+namespace content {
+
+class RenderFrameHost;
+
+// ImageDownloaderDispatcher is specific with RenderFrameHost and
+// responsible for the Mojo connection with ImageDownloader Mojo service
+// in RenderFrame.
+// ImageDownloaderDispatcher provides StartDownload API,
+// send download request via the Mojo connection,
+// and callback caller once got result from the Mojo connection.
+class ImageDownloaderDispatcher : public mojo::ErrorHandler {

[Anand Mistry (off Chromium), 2015/06/12 08:19:38]

I'm strongly inclined to say delete this class and just use the Mojo interface
directly from RenderFrameHostImpl. The error handler is unnecessary since it's
not doing anything useful, and the remaining functionality is just
boxing/unboxing.

[leonhsl(Using Gerrit), 2015/06/15 08:09:43]

I think that ErrorHandler can reset the ImageDownloaderPtr once Mojo connection
error happened, so that if StartDownload() is called next time, we can
re-connect ImageDownloaderPtr to remote service. Otherwise, the
ImageDownloaderPtr will keep non-null and unbound, then later calls to
StartDownload() will just fail silently. 
I'm not sure why GeolocationDispatcher and BatteryStatusDispatcher have no
ErrorHandler, maybe it's functional OK for them not to re-connect even Mojo
connection broke.
And, I thought render_frame_host_impl.cc(h) is huge so I tried to avoid adding
more code into it.. :)

[Anand Mistry (off Chromium), 2015/06/16 07:51:35]

Yes, but the Mojo connection should never terminate since the other end is
strongly bound to the message pipe. If it does, that's a problem, not an
expected condition. Handling the error gracefully hides the issue. There are
times when a disconnection is expected, but this is not one of them.

Also, I know the implementation in the renderer is also bound to the RenderFrame
lifespan, but if that goes, the host side will also be gone, so there shouldn't
be an issue there.

[leonhsl(Using Gerrit), 2015/06/23 02:18:02]

Done.

+ public:
+  explicit ImageDownloaderDispatcher(RenderFrameHost* render_frame_host);
+  ~ImageDownloaderDispatcher() override;
+
+  int StartDownload(const GURL& url,
+                    bool is_favicon,
+                    uint32_t max_bitmap_size,
+                    bool bypass_cache,
+                    const WebContents::ImageDownloadCallback& callback);
+
+ private:
+  // Overidden from mojo::ErrorHandler:
+  void OnConnectionError() override;
+
+  static int next_image_download_id_;
+
+  RenderFrameHost* render_frame_host_;
+  image_downloader::ImageDownloaderPtr downloader_;
+
+  DISALLOW_COPY_AND_ASSIGN(ImageDownloaderDispatcher);
+};
+
+}  // namespace content
+
+#endif  // CONTENT_BROWSER_IMAGE_DOWNLOADER_DISPATCHER_H_