Feature Proposal: Support dynamic or generated attachments

Motivation

We don't have a mechanism for dynamic attachments. There are several solutions used by various plugins:

• Attach as conventional attachments (DirectedGraphPlugin)
• Write to pub as conventional attachments, bypassing Func API (DirectedGraphPlugin)
• Write to subdirectory beneath pub/Web/Topic/ (ImagePlugin, GenPDFPrincePlugin, GenPDFWebkitPlugin, FlexPaperPlugin)
• Write to subdirectory of pub but outside Web directory (ImageGalleryPlugin, RtfContrib)

We need a formal way to support these types of applications

Description and Documentation

We need to meet a number of requirements:

• access controls via viewfile if desired (see Tasks/Item9316 )
• Write needs to trigger Store listeners (see EnableCloudStorageForAttachments )
• Low overhead - rcs versioning of large binary attachments is slow. (See NoRCSForBinaryAttachments )
• Write without access checks - viewing a topic can validly generate attachments.
  • Dynamic attachments shouldn't be recorded in Topic MetaData
• Web accessible via pub (or some other) directory path.

We might also need to version the entire collection of attachments for generated/cached attachments. For example, changes to the parameters of the IMAGEGALLERY macro can require that all thumbnails be regenerated.

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

Implement a structure for dynamic / cached attachments

• pub/cached/Web/Subweb/Topic/[application]/[rev]/attachments
  • [application] is the extension managing the cached files IMAGEGALLERY, DIRECTEDGRAPH, etc.
  • [rev] optional topic rev - if requested by application.

-- Contributors: GeorgeClark - 14 Jun 2011

Discussion

These types of attachments are often generated by data external to the topic, or by that and a combination of topic input. DirectedGraphPlugin, ChartPlugin, ImageGalleryPlugin and many others have these issues. View of the topic can cause the attachments to be regenerated through no fault of the viewing user. And viewing old revisions of a topic can cause the cached files to be regenerated again adding to the overhead.

Various API bypass methods means that any move to a cloud or enterprise document managed storage will have 'holes' in the implementation.

-- GeorgeClark - 14 Jun 2011

The only difference to the plugin's work areas is pub/cache being exposed to the http server. So the question to check at least: what if a work area would be exposed optionally? Some kind of extension of the Foswiki::Func::getWorkArea($pluginName, %attributes) API. Depending on the attribute flags the core would then decide where to place the files, either under working/work_areas/pluginName/... or pub/cache/pluginName/....

With regards to the structure under pub/cache, I'd prefer a similar structure to the work areas for simplicity.

Let's further add to the specs of pub/cache/... that it is safe to purge all or parts of the pub/cache at any time with the responsible application being able to recreate the removed files on demand.

Also, this directory hierarchy needs to be maintained by move/renames similar to normal attachment or topic or web move/renames.

Added some more plugins that pollute the attachment area storing auto-generated content w/o attaching it.

-- MichaelDaum - 14 Jun 2011