See bug 1202006

For how WebSocket works, we don't append any data in order to create a blob but, what we receive, is the blob content. That content is a nsCString. Instead doing what you are proposing, I want to implement a BlobImplString so that we don't duplicate the string when the Blob is created.

But could we store huge data still in temp files to reduce memory usage?

I would like to mark bug 704447 as duplicate of this.

Isn't bug 704447 about sending. This is about receiving messages.

> But could we store huge data still in temp files to reduce memory usage? Right. So, with this patch, we still have less duplicate memory because we reuse the string logic. About bug 704447, we should implement a similar MutableBlobStorage class in necko. Just because we have bug 704447, are you OK with me implementing this in that bug instead here?

Not sure I understand how bug 704447 and this one are connected. Or would you do all file-backed blob handling in Necko or something? (I don't care too much which bug is used, but as of now bug 704447 is about sending and this one is about receiving message and I was imaging they to be distinct enough things that they should be handled separately).

I guess we could take this string sharing patch anyhow. That should help with smaller blobs, those which won't be using temporary files.

Pushed by amarchesini@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/1239d6e55498 Introducing BlobImplString, r=smaug