Plugin Caching Concept
Requirements
Split images MUST NOT be supported anymore. Add check that split images are not allowed anymore (syntax check). Alternative would be to use the SVG output format with SVG out plugin.
Add global admin configuration for default image format (PNG or SVG) and function to flush the cache.
HTML image maps MUST be supported.
No special requirements for cluster mode (SUPPORTED but no special implementation)
Provide some performance logging when log level is set to DEBUG.
Only cache static macros e.g. the {plantuml}version{plantuml} output or {spacegraph}, {linkgraph}, {database-structure}, {database-info} MUST NOT be cached since the output may change on every request. (isCachingAllowed)
Global cache configuration MUST be supported as default for all relevant macros (isCachingEnabled).
Algorithm
var image;
if (isCachingAllowed() && isCachingEnabled()) {
var cache = cacheProvider.getCache()
var key = hash(macro.source)
if (!cache.contains(key)) {
var renderedImage = render()
cache.put(key, renderedImage)
}
image = cache.get(key)
} else {
image = render()
}
Cache Storage
In memory Confluence Cache (default/preferred) supports cluster (MUST)
File System (/path/to/cache/directory). Is the max files per directory limit a problem? No cleanup of outdated files. Cache directory inside $confluence.home or configurable (admin section of the plugin) (MUST)
External server (like plantuml.com). Either self hosted or external plantuml-server? no native graphviz installation required but setup is more complex! (OPTIONAL)
Page attachment.
exportNameparameter already exists but not the corresponding source hash. store source hash as page property? History of the attachments is not always wanted. (OPTIONAL)
How to configure/specify the cache as macro parameter?
{plantuml:cache=<empty>|none|attachment|fs|server|...)
<empty> → could be the default cache storage e.g. in memory cache
Some considerations from my side:
Rendered images should be cached in file system (confluence.home directory), comparable to thumbnails or imgEffects. Confluence caching API is suitable to keep serializable objects in memory, but not for (large amounts of) binary data.
Don't use page attachments as cache. Rendered images are temporary data and should not spam the system with previous versions.
Caching must be enabled for all images by default, without user interaction (macro parameters). We need to ensure scalability and performance on large Confluence instances, and cannot leave the decision up to the users which caching parameters to set. Users aren't (and shouldn't be) concerned with the performance impact of their content.
Chaching should be provided for static {plantuml} and {flowchart} macros (model / diagram code described locally in macro body). Caching for the other macros ({spacegraph}, {linkgraph}, {database-structure}, {database-info}) is not expedient, as the data model is highly dynamic and depends on user permissions.