...

1. One or more users on each node in a cluster are hit with the skin compilation time, instead of just the administrator.
2. Deployments of new uPortal code will wipe out all existing skins since they are part of the webapp folder structure and they will need to be compiled again.  Saving the compiled skin into the database would allow for only the admin to be hit with the expensive process and other nodes in a cluster could simply retrieve the compiled result.

Design goals

• Simplified design that fit within client's budgetary constraints, but can be used as a base for more dynamic and feature rich enhancements in the future
• Extremely simple Skin Management UI that non-technical users assigned to perform tenant administrative tasks can use to adjust their skin look
• Skin configuration changes must apply immediately and not require a server restart
• Skin configuration changes apply immediately to all servers in a cluster without administrative intervention
• Approach that can be used in non-tenant situations to allow for simple, basic adjustments to a general uPortal skin experience, hopefully growing more sophisticated over time
• Leverage if possible the same skin technologies used for Respondr
• Do not require duplication of Respondr skin files to allow for configurable skinning to ease long term maintenance.
• Be able to handle a large number of tenants, upwards of 800+, with reasonable system resource impacts.

The Skin Manager is NOT intended to significantly alter the skins as would be done for a typical University deployment where the University's staff would generally copy Respondr's default skin and modify the source files to achieve the desired skin appearance.

...

Future

• Expand the number of skin variables and possibly include images or other elements to allow the skin to be more heavily configured.
• Allow the administrator to 'preview' the skin changes in a way that only the administrator sees the affects of the changes until the skin changes are persisted.
• Enhance the security infrastructure to limit the users who can configure a skin so a delegated administrator can affect only their skin and not other tenant's skins.
• Expand to a database-driven strategy where the skin is stored in the database and not necessarily on the file system.

Opportunities for consideration

• Move skin compilation into an asynchronous task on a non-render thread, getting the details right so that uPortal rendering does not block on in-process skin (re-)compilation and users do not get half-baked in-process skin artifacts during skin (re-)compilation.