[Webkit-unassigned] [Bug 36903] Implement BlobBuilder internal class for BlobBuilder support as defined in FileWriter

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=36903





--- Comment #7 from Dmitry Titov <dimich at chromium.org>  2010-04-09 23:53:42 PST ---
It is much better now. Thanks for iterating on it! I don't think it can go in
in this form, but added code definitely added some clarity.

A few points:

It seems converting strings at getBlob time is just fine indeed, for the
reasons you mentioned. Obviously, we'll not want to do the same for file
fragments but it's not in this patch.

Looking at the patch, I think we can make what you have as CombinedBlob to be
the only type of the blob... A Blob. It would be always a list of BlobItems. A
BlobItem would be an abstract class, with implementations like FileBlobItem,
StringBlobItem, ByteArrayBlobItem.When File derives from the Blob, such Blob
would only have 1 FielBlobitem in the list... StringBlobItem would be the one
constructed from string and stored in a mutable list of BlobBuilder. Once
BlobBuilder::getBlob() (it probably should be createBlob()) is called, the new
list created, with FileBlobItems just copied, and StringBlobItems replaced with
ByteArrayBlobItems, with encoding and current endings attached.

BTW, why do we need to make all Blobs (or BlobItems, if we'll have them)
ThreadSafeShared? I suspect it's because of the FileThread? It would be
unfortunate, since it would slow down cases when FileThread is not in the
picture (building a blob and sending it via XHR does not require thread
safety).

Also, and it may be a bigger issue, it is unclear to me what is the story about
BlobBuilder and FormData. They feel almost identical objects. It seems we might
want to have one of those 'lists of blobs builders'.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.