idb.filesystem.js icon indicating copy to clipboard operation
idb.filesystem.js copied to clipboard

entry.toURL() should create a blob url instead of filesystem URL

Open ebidel opened this issue 13 years ago • 8 comments

Unsupported browsers don't understand filesystem: URLs so they cannot be used out of the box.

The motivation for even implementing toURL() was to make the lib compatible with filer.js.

I should look into this.

ebidel avatar Apr 30 '12 22:04 ebidel

Hey any ideas how one could implement this? The problem is see is that for filesystem toURL() is synchronous but creating a blob url can only be done asynchronous i think. One idea i have is to generate the blob urls when the blobs are stored and save them in a map so that one can access them later in a synchronous way.

BenjaminDobler avatar May 03 '13 22:05 BenjaminDobler

Right now .toURL() does what the Filesytem API does, which is to generate a filesystem: URL string.

Creating a blob and a blob: URL from is are also synchronous operations. There's a rerfernce to the file stored is stored deep in the library, so you could do something like this:

function toURL(entry) {
  // TODO: cleanup URLs created using revokeObjectUR().
  if (entry.isFile && entry.file_.blob_) {
    var blob = entry.file_.blob_;
  } else {
    var blob = new Blob([]);
  }
  return window.URL.createObjectURL(blob);
}

That URL can then be used for previews and whatnot. I've updated the demo to do this.

Down the road, it might be nice to bake this in under the hood. I'd have to change some stuff around though because the filer.js library relies on .toURL() internally.

Hopefully that helps.

ebidel avatar May 04 '13 00:05 ebidel

Ah yeah awesome. I got confused with another issue i`m facing. I really like about the filesystem that you can predict the file urls without actually creating a file. With blobs you first have to create the blob and then the url which is a synchronous act. So the idea was to create all the existing blobs from the db and create all the urls in advance but this might be a memory nightmare :-)

BenjaminDobler avatar May 04 '13 09:05 BenjaminDobler

It's an interesting idea, but we're talking possibly hundres of object URLs. I think you're right it's not the memory tradeoff.

ebidel avatar May 08 '13 04:05 ebidel

I ended up replacing toURL with:

toURL: function() {
  return URL.createObjectURL(this.file_.blob_);
}

I think it makes more sense to make the URL actually work, otherwise is a bit confusing. The memory issue is interesting, but feel the tradeoff for usability is worth it. Perhaps a warning on the index would make sense, to remind programmers since it's a shim, there are some memory drawbacks to toURL and to handle accordingly.

mudcube avatar Oct 13 '14 02:10 mudcube

That might be worth doing, although revokeObjectURL should be called if something tries calling toURL() on the same blob. That would require some bookkeeping.

ebidel avatar Oct 13 '14 21:10 ebidel

How about something like this?

toURL: function() {
    var blob = this.file_.blob_;
    blob.objectURL = blob.objectURL || URL.createObjectURL(blob);
    return blob.objectURL;
}

In FileWriter.write a new blob is created already, so it would remove the temporary variable, and would not be accidentally be written to the datastore.

mudcube avatar Oct 13 '14 22:10 mudcube

I like that.

ebidel avatar Oct 16 '14 20:10 ebidel