Currently USC uses icons delivered by app-install-data-ubuntu for applications in Main and Universe, app-install-data-partner for applications in Partner, and the icon_url property in the Json for commercial applications.
Unfortunately, the app-install-data* packages don't include icons that would be appropriate for the 96*96px space on the software item screen, because that would increase the size of those packages. So it shows a small icon scaled up, which looks ugly.
Examples:
Audacity https://launchpadlibrarian.net/94876609/audacity.png
Bluefish https://launchpadlibrarian.net/94876677/bluefish.png
LyX https://launchpadlibrarian.net/94876707/lyx.png
It would be simpler and more scalable if USC got the icons for any package, regardless of source, from a server in a consistent way. Perhaps USC would request something like
<http://software-center.ubuntu.com/icons/ubuntu/dists/precise/main/s/stellarium?size=96> or
<http://software-center.ubuntu.com/icons/96/ubuntu/dists/precise/main/s/stellarium>,
and the the server would return the icon of the nearest size to what was requested.
If USC requested any size that there wasn't an exact icon for, but there was an SVG icon available, maybe the server would redirect to the SVG one (so that USC could realize "oh, I have that cached already").
Just thinking about keeping services small, focused and resusable, I wonder if a separate icons.ubuntu.com would be worthwhile.
It could import the icons from packages, but also enable other agents (such as devportal) to submit icons for PPA packages or other sources etc.
Also, regarding returning the nearest size - it could also quite simply generate the exact size from the nearest (larger) sized icon or SVG.
And regarding SVG's, with sca we currently *never* store an SVG, generating the raster icons from it during upload - which sounds wasteful, but it came from the requirement to have (1) separate SVG's for different sizes (apparently even though it's scaleable, different detail is included in different sizes), and (2) not being able to find a safe way to serve or strip SVGs (given that they can contain arbitrary JS code etc.). But as (1) isn't relevant in this case, and neither is 2 I think (in that, we don't need to serve the SVG necessarily), such a service could always store the SVG and use it to render an image when an existing raster image isn't available for the requested size.
Anyway, just food for thought.