On 30.1.2012 17:51, Boris Zbarsky wrote:
The same blob should have different URLs in different documents, no?
All documents originated from the same application/session/same-origin?
No. That's the point. Unless you want the lifetime of the Blob to
immediately become "while you have any documents from this origin open".
Or in more concrete terms, while you Google Reader is open, no Blobs
on any google.com page that have had urls created for them would ever
be collected. That seems very bad.
I'd prefer the same URL ( e.g. just passing string using
window.postMessage) . What if I move image element from one document to
another (from top window to iframe) should it have no identifiable
underlying data? I don't like that
It's not great; the alternatives just seem worse.
-Boris
This is just bad... I could go for "same origin is problem", but same
"original document" (other document spawned by this document based on
same origin - iframe, window.open, etc. respecting same origin policy).
Because this is just bad... It's like every time one might think "hey, I
can create application without web server", there's specification
laughing and throwing bricks at you. Again, the easiest way to handle
that is to simply upload that image to server using AJAX, let URL be
returned (regular http://) and no problem at all... There's been great
progress in all regarding FileApi, but being able to work with the
result is just pain...
Is there any way we can come up with any conclusion here? I'm fine with
current one, though I understand that explicit memory management is
little bit odd for some people.
I really do think that while assigning blob to src attribute can make
some some on setter level (just some sense), it makes no sense on getter
level (when what you need to work with is text, like we everybody is
used to for 2 decades and because it is HTML attribute, it must have
some string representation).
Brona
