[Webkit-unassigned] [Bug 67229] ThreadableLoaderClient should support 'didDownloadData' updates

[bugzilla-daemon at webkit.org]

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


Brady Eidson <beidson at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |beidson at apple.com




--- Comment #5 from Brady Eidson <beidson at apple.com>  2011-08-30 16:09:10 PST ---
This doesn't really make sense.

WebCore doesn't download files to disk.  All platforms that implement a concept of downloading a file to disk do so in their API layers.

If the Chromium loader process is doing the loading of data, and that data is for a file download, why does WebCore need to have this platform specific concept introduced to it instead of the Chromium loader process notifying the Chromium UI process directly?

(In reply to comment #4)
> The Chromium ResourceHandle knows how to download to disk (to a temporary file).  I believe that other ports do not need this functionality.  However, it could be generally useful.  It could help us implement XMLHttpRequest.responseType("blob").  

I think you're saying that this could help responseType("blob") on Chromium because Chromium's ResourceHandle already saves to temporary files.  This is not true of WebCore in general.

>It could help us implement NPAPI StreamToFile better (without requiring WebCore to produce a temporary file).  (This is something that Chromium already does for NPAPI.)

I don't understand how this can help any non-Chromium port support this since non-Chromium ports don't have their ResourceHandles stream to files.

> We need this change to support the Chromium WebKit API (WebURLLoader returned via WebFrame::createAssociatedURLLoader).  We need to plumb this notification through the DocumentThreadableLoader.

My understanding of Chromium architecture is not sophisticated, but isn't it actually an opportunity in the case of a file download for the loader process to bypass the WebCore process and notify the UI process directly?

> You can think of didDownloadData as the response equivalent of didSendData, which all ports generate to produce upload notifications. 

Except we already have symmetrical callbacks internal to WebCore - didSendData and didReceiveData.  

This patch tries to add a second form of didReceiveData which will just cause maintenance and code-comprehension headaches downstream.

> XMLHttpRequest.responseType("blob") will need download progress events.  So, this patch seems like a good step forward.

Except for all platforms besides Chromium, those "download progress events" already exist in the form of didReceiveData.

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