Icon/Image Library For Several Applications

My customer have several internal web applications - we are remaking one of them. As the different applications use different images and icons, the IT manager now wants us to deploy a common library for this.

We a bit uncertain on how to do this. The library should have a Editor role to prevent unauthorized changes to the library and at the same time available over the web (global company).

1. Should we host the images in a shared webapp we already have, e.g. Confluence, and link them runtime?
2. Should we host the images as in #1, but link them in compile time?
3. Other
开发者_如何学JAVA

We're using VS2010 and TFS btw.

---

You will probably need to link at runtime since you are talking about potentially editing the library (unless you set up some kind of automated build process to rebuild after you make any changes). Linking the images at runtime shouldn't be too bad since you are talking about web applications (which typically load some resources at runtime anyway).

Depending on what types of applications you are talking about you could just have a shared Images folder, and have a predefined naming scheme for the images in the folder. For example have files called "Save20x20.png", "Open20x20.png", "Cancel20x20.png".

You could then make a quick custom app to view all the images in your image library and their file names, and upload new images as required.

---

I have worked on something similar (http://www.parti.cl which provides icons as a service) which used the following approach:

• a separate image service, whose job is only to provide images
• images are identified by the URL path
• other services then generate HTML that includes the appropriate path as the src attribute for images.
• the path can include information that is used for referrer filtering, if that is important (so, for example, if have multiple sites that you want to provide images to, then you would have some table that has a one-to-many relation between the image ID/name and the sites that can request it).
• the path can also include versioning information. For example you might use a scheme something like http://images.example.com/short-name/version where "short-name" identifies the image and "version" allows you to have manage multiple versions.

You can store the images as binary database blobs (works nicely for small images and for images that are dynamically generated based on the URL) or on the file system. But once you start doing things like using the database to store referrers it's easiest to return the image dynamically (ie you have some code that copies the image from wherever it is into an HTTP response object) rather than relying on a static server.

Finally, use caching where possible to reduce load (both HTTP cache and within your application), but be careful to handle cache validation requests correctly so that when an image changes the new one propagates quickly.

PS Remember that you will need to support SSL too, if images need to be included in secure sites.