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.
>
> 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.

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

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.

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.

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.

--

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.

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


Thank you editors, for reviving this work.

-Charles

Received on Thursday, 3 May 2012 17:42:36 UTC