• All pertinent data (the topic, the pub directory and the notes) should stay together. This makes simpler to abstact the way data are accessed
• A cache mechanism can be needed by complex plugins (say, latex plugin) and in any case it would speed up twiki a lot.
• All data should pass from the twiki authorization mechanism (and this is not the case for the pub stuff).

so I suggest investigating the idea of converting a topic into a directory.

• A topic is a directory. The body part is a file (with a fixed name, say "body" in that directory. The pub part is a subdirectory.
• Subwebs are quite natural, and the notes just belong to a subweb.
• One can have inheritance and permission control. This would allow users to have their own subweb, which in my opinion would be a key feature of TWiki.
• A cache mechanism can be implemented easily: when saving one can convert all non-dynamical parts into a static form (for instance as a perl subroutine, as is done by the template toolkit (www.tt2.org), exploiting the fast perl parser).
• When previewing one can save the body into a temporary file, without the needs of sending it back to user's browser (and allowing the recovery of interruped editing).
• It is easier to synchronize two sites, say one at home and one at work, even if you are not the system manager but you have rights on some subweb.

-- FrancoBagnoli - 30 Mar 2002

-- FrancoBagnoli - 30 Mar 2002