- From: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
- Date: Mon, 30 Jan 2012 21:33:53 +0100
- To: public-webapps@w3.org
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
Received on Monday, 30 January 2012 20:34:23 UTC