Merge lp://staging/~stephen-stewart/snapweb/default-package-icon into lp://staging/~snappy-dev/snapweb/trunk

shouldn't we use a link to the icon on the store so the store is free to change it and reflected locally? I guess this brings in the offline usage question. Then again, the `icon` key in the store will point to this.

Hi there,

This is just a quick change to the default icon (doing the same on SCA) now that we have the correct one from design, it can be approved on that basis or rejected on the basis that all this is going to change anyway.

Also, sideloaded apps?

The store is making icons optional, and is going to send `null` for the icon if a package has been submitted with no icon.

This leaves it up to the client to decide what to do, rather than sending an Ubuntu branded 'no-icon' which would be ambiguous.

This goes the other way around from the original requirement:
"* we drop icon as a requirement (the store will provide a default icon)"

Forcing all clients to provide the icon considered the default of the moment instead of one featured by the store.

o/

Just to fill out the reasoning behind this a little:

If the store mandates a default icon it's mandating a visual style to all clients, Canonical or otherwise, and making it harder for clients to know if an icon is default, user submitted or otherwise (v1 of the default versus v2 of the default?).

By using null in CPI responses, clients can adapt the visual style of a default icon to their own whim, and `null` is much simpler for clients.

Canonical only has a handful of locations to update the default icon, and can do so at a pace that suits the project in hand (for example webdm may not like a v2 default icon until certain updates have been made, visually or otherwise).

I'll not make the bandwidth argument since it's negligible.

"store" being very loosely used. We started off that way and due to what Stephen mentions, we went in a different direction.