This section contains all the information a system administrator needs to know.
The Edia Skin Manager does obey the sakai.properties settings for the skin. That is, it obeys the default skin name (skin.default) and it does use the (skin.repo) setting to seek in the skin on the filesystem.
This tool accesses the file system to manage the skins. It does this by searching in <CATALINA_HOME>/webapps. Any system that places the skins in any other place, for instance by apache configuration, will be incompatible with this tool. Please provide us with a requirements request if you would like specific extra setting to be configured. The skin tool does check if the configured directories look like skin directories.
This tool accesses the file system of the sakai instalation. We do not like it anymore than any good administrator does. Therefore, we took special care writing it. The code is open source, so please read it in case of curiosity or doubt, and inform us first if you find any serious flaw.
The skin home is checked for the images subdir and the tool_base.css. Supposedly skin dirs are checked for tool.css, portal.css and the images subdir. This way, the tool makes sure it is updating/creating/deleting files on places it should. Of course, all directories are driven by the configuration parameters you provide.
Furthermore, the tool checks the contents of the zip file it is unpacking, and makes sure no files "escape" their installation location.
This tool keeps all skins it ever comes in touch with in a database. The zipped versions of the skins are stored in a blob. This means that the database has all the skins and the database is leading when it comes to what skins are installed. At system startup, the tool looks for the skin directory.
Clustering is, in case of this tool, difficult, unless the skin directory is shared along the machines in the cluster. Installing skins in a cluster needs to be kept in sync between the installed instances anyway, so people using their own skins in a clustered environment are already aware of this problem. If the problem becomes really emergent (an institution wanting to manage hundreds of skins in a cluster) we just might develop a "database only" version of this skin that does not depend on the filesystem at all.