W3C home > Mailing lists > Public > public-web-intents@w3.org > June 2012

Re: Web Intents based APIs

From: Robin Berjon <robin@berjon.com>
Date: Wed, 20 Jun 2012 17:29:40 +0200
Cc: Greg Billock <gbillock@google.com>, Claes1 Nilsson <Claes1.Nilsson@sonymobile.com>, public-web-intents@w3.org
Message-Id: <DCFC2320-82A0-472E-920C-7D5895AAE184@berjon.com>
To: Jungkee Song <jungkee.song@samsung.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:47 UTC