Re: createBlobURL

On Mon, Oct 25, 2010 at 6:09 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Thu, 21 Oct 2010 19:47:08 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Thu, Oct 21, 2010 at 3:50 AM, Anne van Kesteren <annevk@opera.com>
>> wrote:
>>>
>>> If that is the only real solution I suggest we do that. We can create
>>> some kind of DOMURL type which is either a DOMString or a URL/Blob/something
>>> and change the relevant APIs.
>>
>> This means that you can't use File objects together with things like
>> .innerHTML (neither the getter nor setter) or things like
>> CSSStyleDeclaration.background. Actually, it doesn't even work with
>> CSSStyleDeclaration.backgroundImage since it can be a list of URLs.
>> And with the CSS Image Values spec [1] it can be something much more
>> complex.
>
> It does not work with backgroundImage either way, as the syntax is not just
> a URL represented as a string, but a special kind of CSS URL string.

Indeed. I suspect background images might be a pretty common use case.
Though maybe people can use normal <img>s most of the time.

>> If we don't want to use blob-URLs at all, we have to track down every
>> single DOM property which deals with URLs and:
>>
>> A. Make sure that it doesn't use strings where URLs is part of the
>> string (like .innerHTML or CSSStyleDeclaration.background). If it
>> does, create a new object model that breaks down the string into
>> components where the URL is a separate component.
>> B. Make it take a DOMURL instead of a DOMString
>
> Right.
>
>> While I agree that memory management is a horrible thing to thrust
>> upon developers, I really don't see an option here. It would
>> complicate matters hugely in cases like
>> CSSStyleDeclaration.backgroundImage. Can you even make a proposal for
>> what the object model would look like which would work for [1]?
>
> The CSS WG is working on an a better object model for CSS values that would
> cover that case.

Like I said, I think creating an OM that covers all the cases here
would create something very complex. I'd love to see a useful proposal
for [1].

>> And as stated before, I think a hugely mitigating factor here is that
>> the amount of memory leaked is very small.
>
> But not small enough apparently to simply not bother with a way of cleaning
> it up.

Yup. I don't think any leak > 0 is small enough not to bother cleaning up.

>> What I think we should do is to fine the places where people are most
>> likely to use blob-urls and in those cases change DOMString to DOMURL.
>> Such as HTMLImageElement.src like Darin proposes. But for the
>> remaining places keep createObjectURL/revokeObjectURL. I would imagine
>> that by just fixing a handful of properties we can cover 95% of the
>> use cases and make those not require the author to do memory
>> management.
>
> 95% seems way higher than our typical 80/20 goal. Why do we want to even
> bother with covering the other cases? We could start out with just DOMURL
> and if there is a real pressing need for more only then introduce those
> methods instead of doing everything right away.

I think this would be a significant limitation. Maybe not in the
number of sites using it, but in the number of things that you could
build. If this really is what everyone wants to do though, I guess I'd
be fine with leaving createObjectURL out of the spec for now and just
leave it vendor prefixed in Firefox. Though so far you are the only
one that has suggested this. Possibly also Maciej who a long time ago
raised concerns about the resource-managament-through-string-value
problem too.

>> [1] http://dev.w3.org/csswg/css3-images/

/ Jonas

Received on Monday, 25 October 2010 23:49:17 UTC