Invoke AttachmentUploader and update AttachmentIds.

sync/protocol/attachments.proto

Index: sync/protocol/attachments.proto
diff --git a/sync/protocol/attachments.proto b/sync/protocol/attachments.proto
index e08e2b052ceb73293751e4ec11a75a5869224fb3..248300017daf2a1da880b4afe603dfc129f2957d 100644
--- a/sync/protocol/attachments.proto
+++ b/sync/protocol/attachments.proto
@@ -19,6 +19,8 @@ message AttachmentIdProto {
   // Uniquely identifies the attachment. Two attachments with the same unique_id
   // are considered equivalent.
   optional string unique_id = 1;
+  // Server url to download attachment data.
+  optional string url = 3;

[maniscalco, 2014/05/09 18:12:11]

URL may be too specific because it encodes both the service endpoint and the
attachment.  I'd like to explore some options:

Instead of url, we could store some blob id and have the client know which
endpoint to use (prod, test, staging, etc.).  The downloader would then need to
know how to form the URL for retrieval.

Another approach would be to replace url with a backend specific type (a proto
message) that's logically private to AttachmentUploader/Downloader.

Let's chat more about this in person.

[pavely, 2014/05/13 23:06:44]

I needed to start with something so I put url.
We need to decide what's it going to be, it needs to be flexible for future
change of attachment server.
Two options:
1. Have one string field and let code in AttachmentService interpret it.
2. Have attachment server specific proto and abandon it if we decide to migrate
to different attachment server.
I think #2 is simpler.

For now let me just remove this field from this change. We'll add it when we
know what it will look like.
On 2014/05/09 18:12:11, maniscalco wrote:

[maniscalco, 2014/05/15 20:09:28]

SGTM

On 2014/05/13 23:06:44, pavely wrote:

 }
 
 // Metadata for a single attachment.