- From: Robin Berjon <robin@berjon.com>
- Date: Wed, 20 Jun 2012 17:29:40 +0200
- To: Jungkee Song <jungkee.song@samsung.com>
- Cc: Greg Billock <gbillock@google.com>, Claes1 Nilsson <Claes1.Nilsson@sonymobile.com>, public-web-intents@w3.org
Hi Jungkee, On Jun 5, 2012, at 10:20 , Jungkee Song wrote: > [Jungkee] this is exactly what I have been pondered upon. The Gallery API certainly needs a type to return “mediaObject” (and its array.) Regarding Blob vs URL, I tried both in the demo (though I sent the JSON stringified object with metadata in fact.) The result is, with the service side hosted on a public node server, the Blob approach does not seem to work well (even only for dozens of hundred-KB-size images.) > I think if we would take the Blob approach into account, we need to add a way for the invocation side to asynchronously access the returned data in the callback. The problem here is that as currently implemented, passing a Blob over requires your UA to download the entirety of the content before the blob can be passed over. But I don't think that that's a requirement enforced by the FileAPI spec for Blobs — it's just the way it's implemented. You would be able to pass Blobs over with good performance if it were possible to construct a Blob based on a URL in such a way that the URL would only be fetched when the Blob is read. To make this more interesting, SOP restrictions ought to apply to the context in which such a URL-based Blob is created, but not in the context in which it is read. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Wednesday, 20 June 2012 15:30:10 UTC