Re: [w3c/FileAPI] Support `Response` in `URL.createObjectURL` (#97)

@mkruisselbrink 

> Revoking the URL on use. This one is very tricky too. How do you define use? The specs as currently written resolve blob URLs when the URL is parsed. Would it be that parsing that revokes the URL? Or if not, and it is the fetching that revokes the URL, how do you deal with other fetches that already resolved the URL but haven't fetched it yet. Should those start to fail? But that would be inconsistent with explicit revocation which doesn't have that behavior. So this also seems like it's given these URLs very different semantics than existing object URLs.

Auto revocation is in the spec already and is left up to the host to define: https://github.com/w3c/FileAPI/blob/3b94136ef959a191f8953d435280008cc7ea8d76/TR.html#L1761

> Limit the scope to a single realm/document: seems sort of like a reasonable thing to have, but again very different semantics than existing object URLs (although to be fair, this is how chrome implements object URLs for media sources).

This doesn't seem to be a + or -?

> So since what you're describing is very different in pretty much every way from existing object URLs does it really make sense to even have this in the same API/scheme?

IDK, but this seemed like the place to do it rather than try to make an entire new spec. The object URLs already have iffy lifetimes and using them after revocation can cause odd effects, this doesn't seem to add too much ontop of that in my opinion.

> Would it possibly make more sense to define a new scheme for this, have API on Response (or Body, but that wouldn't have access to the headers) that generates one of these new type of URLs. And for this new type of URL we could then do the: auto-revoke on first fetch (and don't resolve until they are fetched, which should be fine since we wouldn't support manual revoke), and limit scope to the realm/document that created them?

What is the significant difference with this and extending the existing `blob:` scheme? This seems to just be wanting to make a new scheme with different defaults? I'm fine keeping the defaults of the existing scheme.

> That seems like it would address your usecases, without making object URLs more powerfull/complicated than they already are, and without having to support the explosion of possible configurations that introducing multiple separate flags would cause.

Wouldn't this just move the explosion to this new scheme? I'm not sure the idea of making a new scheme reduces overall complexity in any way.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/97#issuecomment-365040227