[SystemInfo API] Rewrite storage info provider using storage monitor impl.

chrome/common/extensions/api/experimental_system_info_storage.idl

 // 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.
 
 namespace experimental.systemInfo.storage {
 
   enum StorageUnitType {
     // The storage has fixed media, e.g. hard disk or SSD.
     fixed,
     // The storage is removable, e.g. USB flash drive.
     removable,
     // The storage type is unknown.
     unknown
   };
 
   dictionary StorageUnitInfo {
-    // The unique id of the storage unit.
+    // The unique storage id. It is persistent between storage attachments.
     DOMString id;
+    // The mount path of the storage unit.
+    DOMString location;

[Greg Billock, 2013/06/18 18:24:52]

Does this get exposed to apps? That seems like a potential problem. There's no
reason to expose this, right?

[Haojian Wu, 2013/06/21 05:49:04]

Currently I'm not sure. The systemInfo.storage api definition is still pending
and we need to communicate with extension team. This CL is only for rewriting
StorageInfoProvider rather than changing the definition. According to hongbo@
review comments, I add location field here. 

[Hongbo Min, 2013/06/22 09:52:28]

The reason why it should be exposed is, it could tell user which storage is
mounted, on desktop, user might go back the underlying OS to check it.

[Greg Billock, 2013/06/24 16:55:38]

That's sensible. I think we should work to make the name more informative,
though. Especially as that's going to be more useful cross-platform -- there may
not really be a user-helpful location for some storages (i.e. MTP devices). How
about passing the name instead of the location?

[Hongbo Min, 2013/06/25 01:55:07]

Agree!

[Haojian Wu, 2013/06/26 03:22:39]

Does this means changing the IDL name "location" to "name" and retrieve the
value through "StorageMonitor::name()" instead of "StorageMonitor::location()"?

[Greg Billock, 2013/06/26 17:32:48]

Yes. That sounds right. I saw a note from Steve that he supports this change as
well.

On 2013/06/26 03:22:39, Haojian Wu wrote:

[Haojian Wu, 2013/06/27 09:17:59]

Done.

     // The media type of the storage unit.
     StorageUnitType type;
     // The total amount of the storage space, in bytes.

[Greg Billock, 2013/06/18 18:24:52]

Document what the default values are in case we can't establish the capacity or
available capacity.

[Haojian Wu, 2013/06/21 05:49:04]

Done.

     double capacity;
     // The available amount of the storage space, in bytes.
     double availableCapacity;
   };
 
   dictionary StorageChangeInfo {

[Greg Billock, 2013/06/18 18:24:52]

How about "StorageCapacityChangeInfo"?

[Haojian Wu, 2013/06/21 05:49:04]

Done.

[Haojian Wu, 2013/06/23 07:59:16]

Now I doubt whether we should change the name here according to the
https://code.google.com/p/chromium/issues/detail?id=252994

[Greg Billock, 2013/06/24 16:55:38]

I think the new name is fine -- we can update the docs as we move things out of
experimental.

     // The uniue id of the storage unit already changed.

[Greg Billock, 2013/06/18 18:24:52]

"unique"

[Haojian Wu, 2013/06/21 05:49:04]

Done.

     DOMString id;
     // The new value of the available capacity.
     double availableCapacity;
   };
 
   // A dictionary that describes the add particular storage device watch
   // request results.
   dictionary AddWatchResult {
     DOMString id;
     boolean success;
   };
 
   callback StorageInfoCallback = void (StorageUnitInfo[] info);
 
   callback AddWatchCallback = void (AddWatchResult info);
 
   callback GetAllWatchCallback = void (DOMString[] storageIds);
 
   interface Functions {
     // Get the storage information from the system. The argument passed to the
     // callback is an array of StorageUnitInfo objects.
     static void get(StorageInfoCallback callback);
 
     // Monitor a particular storage device available change capacity.
     static void addWatch(DOMString id, AddWatchCallback callback);

[Greg Billock, 2013/06/18 18:24:52]

Should attachment/detachment notifications be spliced in here? The
StorageUnitInfo already has the type information. Should attachment/detachment
notifications follow this same API path?

[Haojian Wu, 2013/06/21 05:49:04]

Here we keep the systemInfo storage api definition the same as
media_galleries_private. 

[Hongbo Min, 2013/06/22 09:52:28]

Haojian, please have a look at
https://code.google.com/p/chromium/issues/detail?id=252994 

[Greg Billock, 2013/06/24 16:55:38]

Yeah, these are going to split as most of the API moves out of experimental, so
it should stay as is.

 
     // Remove the monitor of a particular device.
     static void removeWatch(DOMString id);
 
     // Get all the watched storage devices.
     static void getAllWatch(GetAllWatchCallback callback);
 
     // Remove all the storage devices monitors.
     static void removeAllWatch();
   };
 
   interface Events {
     // Fired when the storage device available capacity is changed.
     // |info|: The changed information for the specified storage unit.
     static void onAvailableCapacityChanged(StorageChangeInfo info);
 
     // Fired when a new removable storage is attached to the system.
     static void onAttached(StorageUnitInfo info);
 
     // Fired when a removable storage is detached from the system.
     static void onDetached(DOMString id);
   };
  
 };