introduced iconset infrastructure

[kaikreuzer]

Signed-off-by: Kai Kreuzer [email protected]

[kaikreuzer]

This PR is just as a preview to give you the chance to provide feedback.
I still have to add some icons, tests and documentation.

[dnobel]

%icon% is always the category of an item, right? Should we change it to %category% to make it clear

[dnobel]

Some general comments/questions:

• I´m not sure about the performance. If you have a lot of IconSets for each icon request all ItemProviders are asked if they provide an item for the category, pattern and state combination. This results in a lot of file lookups, especially for dimmer items. But I just read your comments, if this does not make any performance problems, OK.
• In the sitemap you explicitly set an "icon", not a category. But at the end it will be treated as a category, when given to the IconProvider. This seems to be a bit inconsistent. Even if it might not be relevant for the current sitemap, it´s something that must be discussed for the new sitemap concept.
• The format: If a UI always requests a SVG, because the chosen Icon Set supports SVG, someone who wants to add his own icon has also provide a SVG version of this icon. Because I think from the current implementation the file lookup will fail and no icon will be provided.
• I don´t really understand the Icon Set ID. Let´s say we have different Icon Sets availalbe, does the UI always have to send an Icon Set ID, because otherwise no icon will be returned? Should we store a mapping between Icon Set IDs and IconProviders, to not always iterate through all IconProviders? If I specifiy a concrete Icon Set, can other Icon Providers still return Icons, even if they don´t support the requested set?

[kaikreuzer]

Thanks a lot for the review. I have incorporated all your feedback.

I´m not sure about the performance.

I don't think this is critical. Most of the behavior actually existed already before. I doubt that you will have many (>5) icon providers ever in the system. And by returning 304s, all efforts are usually just a one time effort.

In the sitemap you explicitly set an "icon", not a category.

I have updated all code to now speak about categories, I only refrained from updating the DSL, since this would have too much impact. But yes, for a future sitemap version, this wording should then be aligned.

The format: If a UI always requests a SVG

As written in my other comment, I think the assumption is fine that if an iconset claims to support SVG, the UIs are allowed to request it for all icons. Anyhow, it can also always happen that a certain category is not available, independent from the format. We could discuss, whether the icon servlet should in such cases never return 404, but rather deliver an empty image to the UI, so that this does not need to deal with 404s.

does the UI always have to send an Icon Set ID, because otherwise no icon will be returned?

No, the icon servlet uses "classic" as a hardcoded fallback, but with kaikreuzer@18bbb9c, this is now also configurable through ConfigAdmin.
Additionally, the UIs could offer a configuration which iconset should be used - for the Classic/Basic UI, this will e.g. also be configured through the ConfigAdmin.

can other Icon Providers still return Icons, even if they don´t support the requested set?

Yes, as there is no notion of "supports a set". As you can see with the CustomIconProvider, it is absolultly fine to provide icons even though the provider does not declare any sets themselves.

[kaikreuzer]

I have added documentation and a skeleton for the tests (still to be done...)

[kaikreuzer]

Finished with the implementation of the tests. @dnobel, please check - if all is ok, I will squash the commits before the merge.

[dnobel]

I would set this in setUp and/or tearDown method to null

[kaikreuzer]

@dnobel, I have incorporated your feedback and squashed my commits.

[dnobel]

I guess that means I should merge it? :)