deathcap / url4data

get a URL for the given data

url4data

Get a URL for the given data

Usage:

var url4data = require('url4data');

url4data('hello world', 'name', {type: 'text/plain', scheme: ['filesystem', 'blob', 'data']}, function(url) {
    console.log(url);
});

The scheme option can be used to choose the URL scheme, either a single value or an array of schemes to try in order (returning first supported by the browser, so you can fallback to alternative schemes if necessary). See demo.js for more examples.

Supported schemes

filesystem: from the HTML5 FileSystem API, supported by Chrome. These URLs are predictable and semi-persistent. url4data uses the "temporary" not "persistent" filesystem storage, but the URL persists across page reloads (although it can be deleted by the browser at any time).

blob: from the HTML5 File API, supported by most modern browsers. Not predictable (random GUID), but url4data stores the generated URLs in localStorage in an attempt at providing consistency across multiple invocations. Blob URLs might expire on page load or otherwise fairly frequently.

data: URLs are widely supported, but cannot be used everywhere filesystem: and blob: URLs can be used. They encode the data directly within the URL itself.

Why?

Useful, for example, for SharedWorkers which require the same URL to access the same shared worker across multiple browser tabs.

License

MIT

url4data's Issues

filesystem: URL support

filesystem: URLs have some useful properties blob: URLs do not:

• predictable (vs random GUID)
• more persistent (vs revokes when page closed, fs offers 'temporary' and 'persistent')

But they aren't as well-supported in current browsers (supported in Chrome, at least)

see:
http://www.w3.org/TR/FileAPI/
deathcap/rtc-signaller-sw#1
http://www.youtube.com/watch?v=WlwY6_W4VG8#t=43m32s "Google I/O 2011: HTML5 Showcase for Web Developers: The Wow and the How"

https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/
The filesystem URL scheme

There is one more capability that exist in the FileSystem API not covered above. The specification introduces a new filesystem: URL scheme. When loading URLs from filesystem: it returns the contents of files in stored using the FileSystem API. This is a very cool feature for a couple of reasons. First of all these URLs are predictable. Once you’ve stored a file in the file system, you always know which URL can be used to load from it. And the URL will continue to work as long as the file is stored in the file system, even if the web page is reloaded. Second, relative URLs work with the filesystem: scheme. So you can create links from one resource stored in the filesystem to another resource stored in the filesystem.

Firefox does support the blob: URL scheme, which does allow loading data from a Blob anywhere where URLs can be used. However it doesn’t have the above mentioned capabilities. This is something that I’d really like to find a solution for. If we can’t find a better solution, implementing the Google specifications is definitely an option.

data: URL support?

Might be useful to support data: URLs, in addition to blob: (currently supported) and filesystem: (GH-1). Unlike either of those, data URLs don't point to data elsewhere but contain it in the URL itself. They are widely supported, but cannot be used in as many places (at least not for web workers, most commonly):

http://www.w3.org/TR/workers/

Thus, scripts must be external files with the same scheme as the original page: you can't load a script from a data: URL or javascript: URL, and an https: page couldn't start workers using scripts with http: URLs.