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 but the standard locations in the packaged versions are configured so you just add it and it will work. 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 potentially 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.

This option allows access to the scaled versions of thumbnails in much the same way as the usedirect mechanism discussed above does. It's a little bit more secure in that when enabled some protection to your content is afforded by the updating of the .htaccess files within the web server document tree. As with the usedirect, what you're asking for is exposed and the images downloaded will be cached by default. Additionally access control is implemented via the login program, so unless you explicitly log out, other people using the same computer will continue to be able to access all the files (if they know the name) until the next person logs in AFTER the expiry of your lease.

The scaled thumbnails used in this way are cached in the directory pointed to by contentt in the fsloc section of the configuration file. However making use of this cache is enabled by adding serverturl in the server section of the configuration file.

Warning

Unlike the usedirect option, this option is enabled or disabled at a server level and is not configurable by individual users. If you think your users value the normal URL obscurity, you might wish to avoid using it. You should however be aware that since these caches are organised by set number rather than set name, they expose far less than the names of icons do in the case of icon names exposed by usedirect.

The content caching feature was added in WACS 0.9.1 and provides a vastly improved performance when WACS is used in a commercial site. Unlike all the other options discussed above, this option has to be enabled on a per-set basis through manual creation of the cache for the specified set. If a cached version is not available, WACS defaults to handling downloads in the normal way through calling wacszip . It does not create a new cached copy.

The content caches are enabled by creating a content caching directory within your web server document tree and setting the contenti and contentv attributes within the fsloc section of the configuration. The URLs to retrieve them from are set in serveriurl and servervurl in the server section of the configuration file. The caches themselves are maintained using the wacscachectl tools with the wacsvidcomb tool used to create compilation videos from multi-part originals. A detailed discussion of how the architecture works are to be found in the Hosting chapter of the Administration Guide. Please refer to this for more details.