Summarizing my proposal and responses:
A new function - toTempURL:
Legacy clients may have terrible support for extensibility. With some
HTML consumers,
base 64 encoded images are not usable in the global scope. To get around
this, we proposed
using toTempURL(), to save an image to the local temporary files
directory, and return a reference
which the legacy client could support.
The draw back of this scheme is that Canvas would write to a users hard
drive, known bytes, in a known location, (Boris Zbarsky)
and could also write an unrestricted amount of data.
On the latter point, Kristof Zelechovski writes:
"IFRAME where SRC='javascript:...' has the same disk full problem as
Canvas.toTempURL, and a DOS attack can also be launched simply by creating a
large array that will fill the hard drive with virtual memory. In general,
handling OOM conditions is not covered by the specification."
As for Boris' point, I found more agreement from Henk de Koning:
"I think it’s act of storing on the local hard drive that’s 80% of the
risk. If you return a
URL that points to the exact location on the local drive, that adds to
the risk,
but no more than any other scheme that allows script to touch the local
drive."
I suggested to Boris, that perhaps I could tie into a custom protocol
handler,
to hide the location of the file on the user hard drive. Obviously, this
was not
a well thought-out response. Boris replied:
"I guess I'm not clear on one thing: you can add support for
customHandler:// to this platform but not support for data: ? "
At this point, I conceded that perhaps trying to support "data:" was a
better goal than trying to advocate toTempURL.
We're trying now to implement data:image/png support for Internet
Explorer 6.0+.
There are, as we all know, some limitations to the length of a URL that
a browser may accept.
Internet Explorer has great support (though not thorough) for plugging
in custom URL handlers,
and we expect that we'll succeed, despite the long byte-length of a
typical data:base64 uri.
For platforms that can not handle a base64 uri, and for whatever reason
can not be made to do so
by throwing code at it, Ian Hickson writes:
"If it is just working around limitations then it seems better for
you to define this
as an implementation- and platform-specific non-conforming extension"
A new "problem": Short data URLs.
There is likely a cost, though it could be addressed in implementation,
in passing around toDataURL strings.
Compressing a bitmap to a png, base64 encoding it, copying the string,
twice, and decoding it, can be expensive,
and for some implementations and use-cases, completely unnecessary.
If we could reference a short string, of a hundred or so bytes, instead
of a very large base64 string, it may help with
memory management (and related efficiencies).
Ian Hickson writes:
"On the long term I expect once we have a File/Blob API, we'll use that to
expose the canvas data as a file."
My response, while we await such an API, is to perhaps introduce a new
mime output for toDataURL,
one which for now will be implementation dependent, but may hopefully
grow to see more use.
Based on the most excellent usage of css url() syntax in WebKit and Firefox:
.getContext('2d').toDataURL('text/css') would
return the string:
data:text/css;url(#myImage)
Possibly in a serialized form (accepting base64 encoding, and other
typical encoding methods).
We've instructed our data: handler to process the text/css mime-type,
with url(#) attached,
as a reference to a canvas element available in the scope of the document.
New browser releases are using css in a similar fashion: div {
background: url(#CanvasElement); }
By using a data: url, we can add to our data protocol handler, to
support
as well as div { background: url(data:...); }
I'll report to the group when we have a working implementation.
-Charles
