Deliver attach intent to packaged apps

chrome/browser/extensions/api/app_runtime/app_runtime_api.cc

 // 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.
 
 #include "chrome/browser/extensions/api/app_runtime/app_runtime_api.h"
 
 #include "base/json/json_writer.h"
 #include "base/string16.h"
 #include "base/string_number_conversions.h"
 #include "base/utf_string_conversions.h"
@@ skipping 69 matching lines @@
     case webkit_glue::WebIntentData::BLOB:
       intent_data = new DictionaryValue();
       intent_data->SetString("format", "blob");
       intent_data->SetString("blobFileName", web_intent_data.blob_file.value());
       intent_data->SetString("blobLength",
                              base::Int64ToString(web_intent_data.blob_length));
       // NOTE: This second argument is dropped before being dispatched to the
       // client code.
       args->Append(intent_data);
       break;
+    case webkit_glue::WebIntentData::FILESYSTEM:
+      intent_data = new DictionaryValue();
+      intent_data->SetString("format", "filesystem");
+      intent_data->SetString("fileSystemId", web_intent_data.filesystem_id);
+      intent_data->SetString("baseName", web_intent_data.root_name);

[benwells, 2012/08/27 08:25:51]

I don't understand why we need to send the base name here as well ... we don't
for the FileEntry case.

[thorogood, 2012/08/27 22:45:54]

We also send it for fileEntry? The baseName is the name that we're trying to
serve from within the isolated filesystem. (Notably, in both cases below, the
baseName and fileSystemId are stripped before sending to the client).

In the fileEntry case, it is the _only_ file that exists in the FS, and we want
to deliver it directly.

In the filesystem (this) case, it is the only _directory_ that exists in the FS,
and we want to create another fake FS that exists at that directory.

[thorogood, 2012/08/28 07:41:15]

I've discussed this with Ben, and confirmed that delivering filesystem intents
to hosted apps work in the same way as I'm building for packaged apps.

As discussed, the way an attached intent works is:
+ create virtual filesystem (empty)
+ add 'link' to the media device, as a single folder within the vfs
+ create a DOMFileSystem object (from app_runtime_custom_bindings.js) that
refers to the folder *within* the vfs
+ send that DOMFileSystem to the client

+      args->Append(intent_data);
+      break;
     default:
       NOTREACHED();
       break;
   }
   profile->GetExtensionEventRouter()->DispatchEventToExtension(
       extension->id(), kOnLaunchedEvent, args.Pass(), NULL, GURL());
 }
 
 }  // namespace extensions