[Media Gallery] Added code to support mtp device media file system on Windows.

chrome/browser/media_gallery/win/mtp_device_operations_util.h

+// Copyright (c) 2012 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.
+
+// MTPDeviceOperationsUtil provides support to media filesystem operations.
+// It has several utility functions to open a media transfer protocol (MTP)
+// device for communication, to enumerate the device contents, to read the
+// device file object, etc. All these tasks may take an arbitary long time
+// to complete. This class segregates those functionalities and runs them
+// in the blocking pool thread rather than in the UI thread.
+
+#ifndef CHROME_BROWSER_MEDIA_GALLERY_WIN_MTP_DEVICE_OPERATIONS_UTIL_H_
+#define CHROME_BROWSER_MEDIA_GALLERY_WIN_MTP_DEVICE_OPERATIONS_UTIL_H_
+
+#include <portabledeviceapi.h>
+#include <string>
+
+#include "base/platform_file.h"
+#include "base/string16.h"
+#include "base/win/scoped_comptr.h"
+#include "chrome/browser/media_gallery/win/mtp_device_object_entry.h"
+
+namespace chrome {
+
+// See the top of the file for complete class description.
+class MTPDeviceOperationsUtil {
+ public:
+  // Opens the device for communication. |pnp_device_id| specifies the plug and
+  // play device ID string. On success, returns true and updates |device| with
+  // the portable device interface.
+  static bool OpenDevice(const string16& pnp_device_id,
+                         base::win::ScopedComPtr<IPortableDevice>* device);
+
+  // Gets the details of the object specified by |object_id| from the given MTP
+  // |device|. On success, fills in |file_entry_info|. On failure, returns the
+  // corresponding platform file error and |file_entry_info| is not set.
+  static base::PlatformFileError GetFileEntryInfo(
+      IPortableDevice* device,
+      const string16& object_id,
+      base::PlatformFileInfo* file_entry_info);
+
+  // Gets the entries of the directory specified by |directory_object_id| from
+  // the given MTP |device|. On success, returns true and fills in
+  // |object_entries|. On failure, returns false and |object_entries| are not
+  // set.
+  static bool GetDirectoryEntries(IPortableDevice* device,
+                                  const string16& directory_object_id,
+                                  MTPDeviceObjectEntries* object_entries);
+
+  // Writes the data of the object specified by |file_object_id| from the given
+  // MTP |device| to the file specified by |local_path|. On success, returns
+  // true and writes the object data in |local_path|. On failure, returns false.
+  static bool WriteFileObjectData(IPortableDevice* device,
+                                  const string16& file_object_id,
+                                  const FilePath& local_path);
+
+  // Returns the identifier of the object specified by the |object_name|.
+  // |parent_id| specifies the object's parent identifier.
+  static string16 GetObjectIdFromName(IPortableDevice* device,
+                                      const string16& parent_id,
+                                      const string16& object_name);

[Ryan Sleevi, 2013/01/05 03:00:58]

DESIGN: Given that you take an |IPortableDevice*| for all methods but
OpenDevice, why is this not a class with member functions, rather than the
static functions? Seems very C-API reminiscent, and it's not immediately clear
why.

[kmadhusu, 2013/01/07 19:17:26]

I thought an util class with a bunch of static methods is a common pattern. All
these util functions maintains no state and is reentrant. Will it be clear, if I
have a set of free functions in a namespace rather than static methods on a
class? What major benefit do I get by storing |IPortableDevice*| as a member
variable other than one less input param to the util functions? 

[Ryan Sleevi, 2013/01/07 19:29:29]

Classes that are static-method-holders are discouraged in the style guide:

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Nonmem...

"Rather than creating classes only to group static member functions which do not
share static data, use namespaces instead."

[kmadhusu, 2013/01/07 19:36:43]

Fair enough. Will fix it in the next patch.

[kmadhusu, 2013/01/08 03:19:40]

Fixed. Created free functions in the chrome namespace.

[Peter Kasting, 2013/01/08 04:34:01]

If you're going to use namespaces, consider putting these in their own namespace
rather than the chrome namespace (or perhaps in their own namespace inside the
chrome namespace) since they're all related to each other.  But brettw
understands how we're trying to use namespaces better than I do so you may want
to ask him.

[kmadhusu, 2013/01/08 20:55:18]

brettw@ is OOO today. I have sent an email to him regarding this.

[kmadhusu, 2013/01/09 19:25:46]

rsleevi@: brettw@ replied that he is a bit overloaded. He asked us to do what is
most clear for the project. I am fine with putting these functions in their own
namespace (within the chrome namespace).

namespace chrome {
namespace MTP_device_operations_utils {
 OpenDevice(...);
 ...
}  // namespace MTP_device_operations_utils
}  // namespace chrome

WDYT?

+ private:
+  DISALLOW_IMPLICIT_CONSTRUCTORS(MTPDeviceOperationsUtil);
+};
+
+}  // namespace chrome
+
+#endif  // CHROME_BROWSER_MEDIA_GALLERY_WIN_MTP_DEVICE_OPERATIONS_UTIL_H_