Open ebidel opened 12 years ago
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.
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.
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 :-)
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.
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.
That might be worth doing, although revokeObjectURL
should be called if something tries calling toURL()
on the same blob. That would require some bookkeeping.
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.
I like that.
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.