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

> Auto revocation is in the spec already and is left up to the host to define:

Auto revocation was in the spec, was never implemented as spec'ed, because it was never very well defined. Please refer to the latest version of the spec rather than reading old TR versions, as those are pretty much universally meaningless.



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

Not exactly. Specifying (and implementing) auto-revoking in a way that works with URLs that are limited to a single realm, and have different revocation logic than existing URLs is much easier than trying to somehow do the same with the existing blob URLs. So this way we don't support three different flags that could all be turned on or off, but exactly two options: Either we have the current behavior with createObjectURL, or we have this completely different behavior with a completely different API, and hot have to worry about how it interacts across realms, how it interacts with explicit revocation, how it interacts with the early resolution blob URLs need because of explicit revocation etc.

So since the described behavior is different from the blob: behavior in pretty much every way, it seems to me to make a lot more sense to not try to paper over these differences and instead just keep them completely separate. That way there is no confusion as to why certain blob: URLs behave in one way why others behave completely different.

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