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

[bugzilla-daemon at webkit.org]

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





--- Comment #20 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2011-09-02 11:57:30 PST ---
(In reply to comment #18)
> Can contributors working on other ports ignore Chromium breakage when working on network loading now (like it is the case with v8 bindings)?
> 
> Otherwise, adding this even under #ifdef adds burden on other ports that I personally consider excessive.

I don't understand why you view this as an *excessive* burden.  It is simply connecting up some notifications that only the Chromium implementation of ResourceHandle will generate.  No other port needs to worry about didDownloadData.

There is already convention for routing port specific notifications through these interfaces.  Under USE(CFNETWORK), ResourceLoader has willCacheResponse() and shouldCacheResponse() methods, and under HAVE(CFNETWORK_DATA_ARRAY_CALLBACK), SubresourceLoader has supportsDataArray() and didReceiveDataArray() methods.

To be clear, I don't like #ifdefs very much, and I would like loader code to be cross-platform.  I definitely would encourage work that moves us in that direction.  However, it seems unfair to require a higher standard of PLATFORM(CHROMIUM) than what exists for USE(CFNETWORK).

I believe that Bill's patch, with the changes I suggested, gets us to a point where PLATFORM(CHROMIUM) is not unlike USE(CFNETWORK) in terms of the ugliness that it imposes on loader/.  Furthermore, I believe we've identified an opportunity with good use cases that might inspire better abstractions for encapsulating port-specific differences.  That sounds like something we can work on.

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