RE: Gallery API draft review request

Dan, Charles,
Thank you for your comments.

> -----Original Message-----
> From: Charles Pritchard [mailto:chuck@jumis.com]
> Sent: Friday, May 04, 2012 2:42 AM
> To: public-device-apis@w3.org
> Subject: Re: Gallery API draft review request
> 
> On 5/3/2012 5:28 AM, Dan Brickley wrote:
> > On 3 May 2012 10:59, Wonsuk Lee<wonsuk73@gmail.com>  wrote:
> >> Hi. All.
> >>
> >> Below link is pretty version ;)
> >> https://dvcs.w3.org/hg/dap/raw-file/16185b62381d/gallery/index.html
> > Very interesting. Can you give some rough expectation on how large
> > such galleries are expected to be? Apologies if I've missed this in
> > the document.

I believe it'd be better to leave the scale of the usage to the developer.

> > Is the expectation roughly that a 'gallery' sized collection is small
> > enough to be downloaded in a single transaction? Perhaps<  100 items,
> > roughly?
> >
> 
> I expect that to get any larger than a hundred items we'd want to see
> "virtual" URIs and a thumbnail request mechanism.

Thumnails (for images and videos) can definitely be retrieved in the callback data of the pick request. As you mentioned here, a url approach has the origin problem, I am leaning to a blob approach. However, for large items, especially for read-only case (mostly audio and video), the url approach might be useful.

In addition to everyone's comment here, I will be working on some demo code to see the feasibility of each approach.

> For 3.2: Discussion -- We can't pass usable Blob URIs; Such URLs will
> not work across origins.

True. But, for read-only cases, it would be helpful, though. Do you think it will be confusing developers to support both options?

> There was some discussion with Microsoft about the format of Blob URIs.
> Most implementations use a UUID, so the URIs are essentially secure and
> unique. Microsoft was strongly considering using simpler URIs.
> 
> In one of my applications I do still pass Blob URIs, but they're no
> different than using random strings. I have to keep a reference in page
> that sends the Blob URI
> and for the sake of good management, I also have to revoke the object URL.

Right. It would definitely add developers complexity.

> I don't believe we have a mechanism for a window to "share" a custom URI
> (blob: or filesystem:) with another origin.
> XHR was only recently (if that) implemented to have Blob support in
> WebKit/Chromium.

Right. The URI only allows the use of the content as the source of media element. I would like to hear more opinions about supporting url approach for this use case.

> So doing an XHR request typically involves receiving an ArrayBuffer; not
> a good situation for large files AFAIK.
> But, it is supposed to have Blob support.
> 
> --

I will check more on the feasibility of the blob reading through FileReader. By the way, in the draft, I am proposing to use Web Intents for the content and metadata delivery in the callback.

> For large result sets, it would be preferable if we had a {thumbnail:
> ...} option, so as to receive either a set of thumbnails, or a set of
> images with a sprite mapping.

Agreed. The data dictionary of the callback will be defined considering this point.

> It seems like most video picking services are going to be simple URLs
> for viewing, whereas images are more likely to be about editing.

Right. This part, the audio and video usage, makes it hard to decide excluding the url approach.

> 
> Thank you editors, for reviving this work.

Thank you for your comments!

> -Charles
> 
> 
> 
>

Received on Friday, 4 May 2012 12:52:05 UTC