The usedirect mechanism requires a bit of a rethink about how the filesystem on the web server is laid out. It offers some very distinct speed advantages on loading of web pages, but at the same time has some significant disadvantages. The default configuration for Wacs is set so that it is not used. When usedirect is used, the modelpages and others give an actual URL for the icon for each set rather than giving a link making reference to the wacsimg program. This means that the icon is obtained directly from the webserver without any intermediary application being called and will conventionally be cached and that cache utilised where possible.

However doing this moves the set icon outside of the access control afforded by Wacs, so technically it is unprotected - if you're using the security mechanism to restrict content from spouses or minors, this is really bad. If you're using the security mechanism in a subscription web server, people being able to get to a single 120 x 120 pixel thumbnail of each of the sets you have, but not the set itself, is probably of no concern at all. Do bear in mind however that if no web page contains a reference to it, people are unlikely to find the thumbnail's full URL unless they have access to your web browsers history, cache or a corporate firewall log. To avoid being too obvious in such histories or firewall logs wacs normally invokes icons via a fairly anonymous call to wacsimg with a set number as an argument - this would not normally trigger any automatic corporate firewall content flagging systems and such a URL is only valid from the authenticated host itself during the time period of the lease. The Logout option allows for the voluntary relinquishment of a lease ahead of it's expiry time, making this even safer. Other addresses would not be able to display it, nor would the URL be any use after the expiry of the lease. When usedirect is used, the name is obvious, permanent and accessible - it might well trigger corporate firewall content flaggers.

WACS can be simultaneously used in both ways - you could use usedirect when at home, and normal access methods when elsewhere. The consequences of using it elsewhere do of course fall on your head - the above comments about corporate firewalls are informational only and in time, who knows, some rulesets may be updated to specifically detect wacs usage.

To enable usedirect operation, you need to ensure that the fsloc section configuration options seticons, officons, vidicons, dvdicons and addicons all point to locations within the web server document tree (ie /var/www/html or similar). The generate command can then be used to re-create the auto-generated icons under seticons if required; the others will have to be moved (or copied) from their previous locations. From this point on, the icons should someone know the URL by some means, will be accessible to all (unless you restrict them again through the web servers access control mechanism). To enable usedirect functionality, you then add the URL of the web server icon directory to the configuration file using the usedirect keyword.

While the name is slightly misleading and came from it's previous usage to store only rescaled versions of the icons, the scalecache directive specifies a directory in which to place re-scaled versions of the set icons. Each time a specific sized version of an icon is requested, it will be created if needed and copied into a directory tree placed in the directory pointed to by the scalecache configuration variable if that directory exists. If scalecache is not set, it will be retrieved from the usual icon locations and scaled if necessary. The gain here is that the scale cache is organised by set number rather that name, so no database interactions are required to determine if the cached icon is available - the wacsimg command is still used but it runs for a much shorter time and does much less.

The way this works is that if wacsimg is asked for the standard icon for set 14, it simply checks if there is an icon for set 14 at the standard size in the scale cache. If it isn't there, or scalecache is not enabled, it connects to the database, looks up set 14's location and goes and looks for the icon in that location. The main issue with scalecache is that set numbers could potentially “go stale” and it might produce the wrong icon. Additionally, it can take up quite a bit of space. Best practice would probably be to delete or at least expire entries from it over a period of a week or so. This will ensure that active sets, like the newly added ones, are cached but that the cache itself is not swamped by unused and obsolete cached icons.