Work in progress implementation of Icon URI scheme.

Work in progress implementation of Icon URI scheme. 

Submitting to get feedback and direction for the implementation as well as insight on the future of the Icon URI scheme (http://tools.ietf.org/html/draft-lafayette-icon-uri-scheme). The draft currently has provisional registration and will expire at the end of the year.

Current implementation only supports the 3 IconLoader::IconSizes. Only can load icons by file extension; media type and keyword resolution not yet supported. 

The design is based on that of ChromeURLDataManager where we have the URLRequestJob, DataSource and the DataManager. There is definitely some opportunity to refactor out some of the common code in ChromeURLDataManager and IconURLDataManager. An IconURI class has been added to parse icon URIs in accordance to the draft.

See screenshot of test page here: http://goo.gl/gk8d

BUG=54650
TEST=icon_url_data_manager_unittest.cc

[pierre.lafayette, 2010-09-07 02:51:34]

Any comments on the implementation or the draft itself would be very helpful :)
Been procrastinating on this work for a while now.

[brettw, 2010-09-07 16:57:21]

Darin just commented on the bug. I'm also a bit concerned about adding this and
I'm not sure it's the best way to solve the file listing problem, and without
that use case, I'm not sure what this is trying to solve.

Architecturally, I'm not super excited about having this proxy to the UI thread
for each icon request. In the case of a file directory listing, there will be a
whole bunch of requests (potentially many dozens to hundreds). This will
correspond to that many messages to the UI thread. The responses will then cause
us to encode that many PNGs form the icon manager on the UI thread before
sending them back.

I'm concerned both about the number of messages to the UI thread and all the
work encoding the pngs on the UI thread.

[pierre.lafayette, 2010-09-07 17:10:20]

On 2010/09/07 16:57:21, brettw wrote:
> Darin just commented on the bug. I'm also a bit concerned about adding this
and
> I'm not sure it's the best way to solve the file listing problem, and without
> that use case, I'm not sure what this is trying to solve.
> 

Well the file listing problem is just a usage for it. It is something I'm sure
web developers would use. If you check out the Internet Draft, there's a
security section that hopefully addresses any concerns.

> Architecturally, I'm not super excited about having this proxy to the UI
thread
> for each icon request. In the case of a file directory listing, there will be
a
> whole bunch of requests (potentially many dozens to hundreds). This will
> correspond to that many messages to the UI thread. The responses will then
cause
> us to encode that many PNGs form the icon manager on the UI thread before
> sending them back.
> 
> I'm concerned both about the number of messages to the UI thread and all the
> work encoding the pngs on the UI thread.

Is there a reason why we don't decode images on another (dedicated) thread?

[pierre.lafayette, 2010-09-07 20:29:39]

I'm going to close this based on the feedback I've been getting here and on the
bug page. 

Thanks for your comments.

[Paweł Hajdan Jr., 2010-09-08 17:51:44]

Drive-by with a test comment.

http://codereview.chromium.org/3324009/diff/1/6
File chrome/browser/icon_url_data_manager_unittest.cc (right):

http://codereview.chromium.org/3324009/diff/1/6#newcode42
chrome/browser/icon_url_data_manager_unittest.cc:42: for (size_t i = 0; i <
ARRAYSIZE_UNSAFE(passingTests); ++i) {
Please use SCOPED_TRACE in the loops (here and below) to make the error messages
more clear.