tools/android/loading Support "report" tasks in the Clovis frontend

tools/android/loading/cloud/frontend/README.md

Index: tools/android/loading/cloud/frontend/README.md
diff --git a/tools/android/loading/cloud/frontend/README.md b/tools/android/loading/cloud/frontend/README.md
index 7e0689845604ce9d6ead9953194f7e91a1ff2935..33ada163991d1d7f049498ad17a26ec07975049e 100644
--- a/tools/android/loading/cloud/frontend/README.md
+++ b/tools/android/loading/cloud/frontend/README.md
@@ -7,7 +7,8 @@
 Visit the application URL in your browser, and upload a JSON dictionary with the
 following keys:
 
--   `action` (string): the action to perform. Only `trace` is supported.
+-   `action` (string): the action to perform. Only `trace` and `report` are
+    supported.
 -   `action_params` (dictionary): the parameters associated to the action.
     See below for more details.
 -   `backend_params` (dictionary): the parameters configuring the backend for
@@ -36,6 +37,10 @@ following keys:
 -   `emulate_device` (string, optional): the device to emulate (e.g. `Nexus 4`).
 -   `emulate_network` (string, optional): the network to emulate.
 
+### Parameters for the `report` action
+
+-   `urls` (list of strings): the list of URLs to process.

[blundell, 2016/05/11 10:35:39]

I would think we'll also want a mode where you just point to a trace directory
and it processes all the URLs underneath. WDYT?

[droger, 2016/05/11 11:16:27]

Very good point.
This was my initial idea too, but then I decided to go by URLs, because it
seemed much more difficult to implement (see below).

If we do it per directory, then it's also not clear whether we would want that
in addition to the URL mode. Maybe the directory mode would be enough.


The reason why I chose URLs instead of directory is because it is much simpler
to split the work into small tasks (splitting a list of URLs is easy).

If I wanted to take a directory as input, I would need either to:

-reconstruct the list of URLs in the frontend, which means that the frontend
would need to load and call into things LoadingTraceDatabase, which seems a bit
complex (I liked the idea of keeping the frontend relatively dumb, and also
would require some refactoring of the directory structure so that appengine can
reference this code).

- or split the work across another dimension. The most obvious being to find all
the loading trace database files (just by doing a prefix match, and without
loading them), and create one task per file. The downside of this approach is
that these tasks will be rather large.

We can definitely discuss more about this.

+
 ## Development
 
 ### Design overview