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
