create new tag
, view all tags
Related Topics with constructive content: GetRidOfRcs TWikiWithCVS DistributedTWiki MegaTWiki TWikiWithSubversion

I know there have been many different topics that relate to "_topic data storage_" so please help by adding to the list of related topics. I created this to focus the discussion I've found on Codev relating to the tough issues needed to modularize the calls used in the current TWiki code to use a modular storage backend. I do not suspect this is a quick fix or short project. The problem is the coding ties to RCS and/or RcsLite. Focusing first on storage seems a logical approach to me. This leaves the other perhaps contentious question of changing diff for a different topic.

So why do this? The benefits are in making the code simplier to maintain and possible to expand to more advanced and interesting applications like DistributedTWiki and perhaps MegaTWiki.

-- GrantBow - 04 Jan 2003

I've taken the liberty of moving the Related Topics list to the top of this page. And I'll try to go meta:

There are two issues wrt storage of wiki data:

  1. Storage of the "current latest view"
  2. Version control, preservation of old versions.

Version control could totally subsume the storage of the "current latest view". I'm not at all sure that it should. The same argument could be applied to any tool, such as a text editor or compiler:

Q: why bother "checking out" a text *.c file to edit using a tool like emacs, and then compile - why should not all tools just go to the version control repository?

A: using "checked out files" allows multiple version control tools to be used. The text editor and compiler do not need to be tightly integrated with the version control tool.

I'll add more soon, but a quick side point:

I think the "current wiki view" need not be wiki text pages, but could be html generated by the twiki engine from the wiki text. This could allow non-wiki browsers to look at the "cached" wiki pages; the wiki engine would be required only to respond to dynamic requests such as editing, and version control.

-- AndyGlew - 31 Mar 2003

Not sure I follow you, or maybe you have a few points.

If you are suggesting that that HTML be generated from the wiki text and cached so that pages are usually served from the HTML cache (except for editing, ...), there has been other discussion about that, there is a plugin to create the HTML, and, IIUC, at least one TWiki installation is set up that way (can't tell you which).

All browsers are non-wiki, so not sure what you mean there either -- are you thinking of non-HTML browsers -- not even sure they exist, or maybe you mean text-mode (as opposed to graphics) browsers, like lynx, links, or the EMACS thingies (W3M???). Anyway, suggest you do some searching on the site.

regards, -- RandyKramer - 01 Apr 2003

Andy is correct in saying that we have a current topic text and version control text. These are often separated in compile environments with the current version on a different machine to the latest version. This requirements doesn't exist for TWiki. However, the following does:

  • the current version (the .txt files) are searched by normal unix tools - without the pain to grab from RCS or use a speciallised RCS search tool
  • you don't have to have the RCS history file - you can drop in just the text file and TWiki works fine.

I'm also puzzled by the reference to non-wiki browers. TWiki renders HTML for HMTL browsers. HTML caching is not used by the TWiki core as a change in another topic can change the rendering for a specific TWiki page - this can be dealt with by a cahce, but getting this fully right is tough. Plugins for caches are certainly the way to go at present.

-- JohnTalintyre - 01 Apr 2003

StoreDotPm uses a specific interface to talk to RcsWrapDotPm and RcsLiteDotPm. Is this interface documented anywhere yet? Which of the functions defined in those modules and their parent class RcsFileDotPm are used by StoreDotPm and which are just internal utility functions?

If we don't yet have any documentation about the storage-mechanism interface, maybe we should make some, since contributed storage mechanism add-ons could be a real boon to TWiki.

-- WalterMundt - 05 Mar 2004

Documentation could certainly be improved e.g. by added POD comments. I'll see what I can do. Please note that both RcsWrapDotPm and RcsLiteDotPm inherit from RcsFileDotPm. All internal functions start with and underscore.

I had hoped to add a SQL back-end, but never had the time. Another revision control system would in theory be easy, but the replace version function in RCS used by TWiki is not always available.

-- JohnTalintyre - 05 Mar 2004

Yeah, the main question I had was how much of the "public" interface of RcsFileDotPm is used by StoreDotPm? Is any of it simply there to make the other two classes work better? I.e. are the "internal" functions just the "private" ones, or the "protected" ones as well, in C++/Java parlance?

And you could emulate the revision-replace operation on VCS's that don't support it if you were smart about it. E.g. for TWikiWithSubversion my idea was to use Subversion's capability to store arbitrary key=value metadata with any versioned file to do it. You can attach properties to any file, which will be version-controlled, or you can attach them to a specific revision of a particular file, in which case they are "unversioned" and only the latest value is stored. Either could be used for this. For CVS, SVN, possibly others you could probably use the commit message log to track which commits are for which TWiki "revisions" and always use the last commit on a particular "revision" as that revision's data.

-- WalterMundt - 05 Mar 2004

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2004-03-05 - WalterMundt
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.