create new tag
, view all tags
I would like to see a offline version of a wiki. Basically I guess just install twiki on your pc, download the files, and do modifications locally.

Simple option - use remote CVS straight into the repository, and hope the merges are OK! (and that no one tries to get nasty doing manual updates)

Involved option - when you are back online, go to the local 'update' page, which goes through all your changes and, does them on the server. If any conflicts were detected, warn the user and send them to the preview changes window on the server. CVS would probably still be a help in this, but security in cvs will probably still be an issue, so it would probably be more robust to generate appropriate http messages to update the constent using the servers normal scripts/authetication. This would also be necessary for it to work from inside most firewalls.

-- MathewBoorman - 19 Apr 2000

If you use emacs, there is an emacs wiki-mode. The .el is at wiki.el. I found out about it on the C2 wiki, at WikiMode.

Now, I've never used it, so I can't claim it's good or bad or indifferent. I do have a TWiki up on a Linux workstation running Apache (see, there is a reason to run a web server on your workstation) and I'm trying (along with RobertaBennett) to get it running on Windoze, I'm trying the 9x branch and Roberta is doing NT.

Good luck.

-- KevinKinnell - 19 Apr 2000

Agree, an offline Wiki would be great. This would be useful for our support engineers in the field to have access to the extensive information in our knowledge base without a need to connect to the internet. TWikiWithCVS might be the ticket for that.

Another simple possibility would be to have a "read only" offline TWiki. How about using all topics (including attachments) in all webs to generate a bunch of static web pages that are all linked? This would mean that there is no need to run a web server on a laptop, but it would also mean that updates can't be done while on the road.

-- PeterThoeny - 19 Apr 2000

I really like the idea of having an export function, not only for 'real' read only offline use, but also to copy information from a (private) intranet TWiki server to a public webserver.

Some thoughts about requirements for an export script:

  • use a new template (different from the normal 'view') to format each topic
  • generate an index.html file (same as WebHome?)
  • return everything in an archive file (zip, tarball, preferably configurable in twikicfg.pm, or even in UserPreferences)
  • the root of the archive should only contain a directory with the name of the web, all topics/attachements should be put below that directory

-- PeterFokkinga - 19 Apr 2000

My goal would be to allow enhancements to development documentation. I envisage the docs would mostly be used by people offline, and would like to capture their corrections and additions as they use it.

I agree a download of static pages would be good for most people to use as the document. The content would need to differ slightly with a link on each page to the online equivalent, and they would not need many other links, revisions etc.

For the smaller number of people actually doing most documentation updates a offline 'editable' mode could allow them to do them, review their changes overall, and then upload them later. Come to think of it by installing a local Twiki they can use the local Changes page, and the revision history on the local and online page to manually transfer the edits fairly simply. All that is missing in that case would be an efficient mechanism to refresh the local Twiki. I suspect this is where TWikiWithCVS would be ideal.

More thoughts... I guess you would want to do this at a level of a TWikiWeb, so that you could support mulitple local Wiki Mirors from different sources. You would maintain your own Main subweb, and just mirror the appropriate directories for the subweb.

Bring on the 95/NT port, as until then, OfflineWiki will be limiting for my target audience. Have you looked at the Perl library that is (somewhere) on the net (I'll look it up later in the mag I saw it in , at work). They have a goal of porting most unix utils to perl to allow enhance perl as a multiplatform tool.    I use the Cygnus Cygwin32 stuff to do Unix on Win. I've been toying with both Apache and Savant as the httpd. -- kk 28 Apr

-- MathewBoorman - 24 Apr 2000

AlainPenders said on twiki-dev@listsPLEASENOSPAM.sourceforge.net:

We're having the following issues for which using CVS would provide a good solution:

  • We have several offices, a lot of people who are often travelling, as well as people at remote locations without permanent internet links. In all these cases access to the documentation is either impossible or a major pain (need to do mirroring, and editing is impossible). Being able to create a fast copy using CVS, and to merge in the changes made while not being connected to the main server helps a lot.

  • As we manage technical documentation in it, that documentation is bound to change between software releases. Using CVS allows to manage these different documentation trees, so that end-users can look at and edit documents belonging to the right software version.

We should distinguish between these four different needs:

  • ReadOnlyOfflineWiki
    • For people in the field who have a need to browse and search.
    • Pros:
      • Only web browser needed for browsing.
    • Cons:
      • Can't edit content while offline.
    • How:
      • Generate static HTML pages and a big index as a search replacement.
      • Copy the pages (only diff?) periodically to offline machines.

  • ReadWriteOfflineWiki
    • For people in the field who have a need to change content while offline.
    • Pros:
      • Can edit and search content while offline.
    • Cons/catch:
      • Setup issues: Web server and TWiki needs to be installed on client.
      • Intelligent merge is necessary, like for example a TWikiWithCVS.
    • How:
      • Work on content independently on different TWiki installations.
      • Synchronize periodically.

  • WikiClusters
    • For large corporations who have a need to work on content in the local offices without depending on the WAN (internet).
    • Pros:
      • LAN speed for collaboration.
    • Cons/catch:
      • Setup issues: Web server and TWiki needs to be installed in each office.
      • Intelligent merge is necessary.
    • How:
      • Synchronize constantly in the background.

  • WebsitePublishing
    • For companies who would like to author their web site the Wiki way. This is the realm of Manila.
    • How:
      • It is necessary to support the edit - approve cycle.
      • Define what gets published, depending on the TWikiCategoryTable.

Please follow up in a relevant topic.

-- PeterThoeny - 23 May 2000

Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r10 - 2004-10-11 - WillNorris
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.