Re: [FileAPI] createObjectURL isReusable proposal

On 3.2.2012 7:51, Charles Pritchard wrote:
> On 2/2/12 10:40 PM, Bronislav Klučka wrote:
>>
>>
>> On 3.2.2012 7:34, Bronislav Klučka wrote:
>>>
>>>
>>> On 28.1.2012 8:47, Ian Hickson wrote:
>>>> On Sat, 28 Jan 2012, Kyle Huey wrote:
>>>>> On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher<darin@chromium.org>  
>>>>> wrote:
>>>>>> I'm not sure what a concrete proposal would look like.  Maybe
>>>>>> Element.URL.createObjectURL or just Element.createObjectURL?
>>>>> Wouldn't returning an object (which can be GCd) be a better solution?
>>>> The whole point of the API is that we have an object but need a 
>>>> string (a URL).
>>>>
>>>
>>> We could always leave the revokeObjectUrl call to simply delete 
>>> content from cache...
>>>
>>> Brona
>>>
>>
>> BTW. I know It sounds a lot like something that can be done with 
>> FileSystem API, but I hope the ease and benefits for developers are 
>> clear here, FileSystem API would be overkill for this (and easier to 
>> implement for vendors without FileSystem API implemented yet)
>>
>> Brona
>
> Yes, revokeObjectURL would simply mark the content as "dirty". Some 
> other cache / trash cleanup takes care of the garbage.
> There's nothing in createObjectURL that says a Blob must be in RAM.
>
> For all intents, createObjectURL could put items into the Temporary 
> FileSystem for a domain. The Chromium team has already lifted file 
> size limitations on the temporary file system. That's with the 
> understanding that items can be evicted at any time.
>
> However, createObjectURL specifies that an object may not be evicted 
> until the page is navigated away from, or until revokeObjectURL is 
> called.
> Persistence is typically limited to 5MB per domain. Or something like 
> 10MB when localStorage is added to the mix.
>
I've mentioned FS API just as response to "you can do it with FS API"... 
This may have nothing to do with FS API on implementation level.
> It seems like this is an interesting middle-ground.
>
> The battle is in the CSS-realm.
>
> With the <img> tag, we can simply hook into onerror. Within CSS, we 
> are unaware as to whether our contested resource has been loaded.
> There are of course, iframe tricks, which are used for font loading.
>
> Lots of subtleties in this area.
So it would be stuck there until onunload, how many 1GB videos are there 
as source to CSS image?
CSS+cache should be a regular deal when it comes to implementation I 
assume.

>
> I see no reason why an author should expect to stash 100MB of objects 
> into createObjectURL, nor any reason why a UA could not manage 100MB 
> for the application lifetime; the user can certainly be informed, as 
> they are with other APIs, if the limit has gone beyond what the UA is 
> comfortable with. That's always useful for debugging/development -- 
> when infinite loops are a normal part of the web experience.
Well how about 1GB video :D or 100 high resolution images?
But as you say.... there's no reason, why desktop application (browser) 
should have any problem with it...
And yes... there may be some disk space problems on rare cases, but such 
problems can appear in any regular usage of any program (well, there's 
simply no space left)...
>
> -Charles
>

Brona

Received on Friday, 3 February 2012 07:09:06 UTC