[whatwg] The Rapidly Approaching Dawn of data uri

[Charles Pritchard]

Hello All,

Though this is more of an implementers discussion, it certainly has a place
amongst developers (users).

I've come to see that data-uri embedded resources will grow as a practice.
They're just plain handy. More, the Canvas standard really expands their 
usage.

At present, it's quite difficult to get the binary code for a jpg image; 
you must
first draw it to a Canvas and export it as a png. XmlHttpRequest with binary
support makes this a little easier -- but you still must run a 
window.btoa call,
something generally unsupported and prone to failure.

The localStorage API allows us to save dynamic image resources in a web 
application,
when they're not included by the applicationCache manifest. Again, we 
see data-uri
images coming into use.

And this is where my implementers note becomes distressing:

Currently, we're all copying these large binary objects as base64 strings.
There's nothing wrong with base64, but why in the world do we have so many
unnecessary memory copies?

I don't expect that DOMDataUri will become a primitive, but I do suggest
a closer look at the state of things.

With an opaque object, one which does have a simple toString() matching
current data-uri/base64 features, we could cut down tremendously on memory
copies and memory/disk usage.

The Blob API is very much intended to solve some of these issues, but I 
really
think that we need an intermediate step, to solve these issues prior to 
2012.

DOMDataUri {
  string toString, // returns a encoded in the current StringFormat setting.
  bool noPrefix, // skip the data:mime/type,encoding prefix when 
returning toString.
  string mime,
  string encoding
}

Something along those lines will allow some easy optimizations to our
current data uri/base64 string handling. Mainly, we won't need so many
data copies. But, as well, it could provide an easy transition to Blob 
interfaces in the future.


-Charles