Filesystem Based Wiki
Filesystem Based WikiFile system based wiki is a wonderful idea for personal or not-ready-for-publish contents. As someone suggested that someday browsers might add wiki as a tag so that the browsers can view wiki formatted pages directly. Before that, I think, there is one import thing wikinote like system might be able to do: try to support all html tags. If your wiki does not support any correct html tags, pass them into the converted html pages so that they can be viewed by a browser.
I don't care if I need to use a browser to preview a wiki page, everyone has got a browser already installed in their computer system anyway, whether it is Linux, Windows or Mac OS. However I care if something can be done in normal html pages and cannot be done in a wiki page. Even worse, the wiki system prevent me from using html tags.
For example, I would like to have mathml math expressions and svg images embeded in my wiki pages, using html tags or wiki tags, and the wiki system should just pass that into the converted html pages so that my browser can view and print them. A GOOD wiki system should not forbid any correct html tags. Just pass them into converted html files, at least FireFox can view them correctly and IE with some plug-ins can view them as well.
So my requests for a good file system based wiki, or something like wikidpad, are
By FilesystemBasedWiki I mean a wiki that is not based on a Web server, but, rather, a wiki-like system that is based on files living in an ordinary Unix or Windows filesystem.
Motivation: the page WikiForLiterateProgramming describes one reason why I want to do this. There are others.
Existing Tools
Some existing tools, such as wiki mode in emacs, run wikis in existing filesystems, but they fail one key wiki criterion: they are not ubiquitous.
Where I work, many people do not use emacs. Moreover, most of the emacs users do not have wiki mode configured. Thus, most people cannot simply go up to an emacs wiki page, and use it.
There are any number of Web-based wikis that store text in ordinary files. But they involve running a Web server. I am looking for a non-Web-server-based implementation (or at least one that can access arbitrary files on the client machine where the browser is being run).
Ubiquity
I believe that the key aspect of wiki is its ubiquity. (See WhatIsUbiquity.) Web browsers are as close to ubiquitous as anything can be in the world of computing.
Therefore, I think that a FilesystemBasedWiki should place wiki pages in ordinary files that can be opened by a Web browser, browsing using file URLs. The Web browser should recognize the file type. This may require that the filtype be one of the ubiquitous file types such as *.html.
(It may be desirable to have other tools that can also look at FilesystemBasedWiki wiki text files. It may be desirable to use a special file type, via a filename extension, such as *.wiki.html, or via Unix #! type magic numbers or executable scripts. But these should not interfere with having an unmodified Web browser be able to handle the wiki text file.)
(It is not acceptable to say that a user could simply add a new file type to his association list, or to his MIME type mappings. The goal is to have a totally unmodified Web browser be able to look at a file. All Web browsers can handle HTML.)
Wiki Text Files
We want the wiki text files to be as text-like as possible, so that ordinary text editing tools can be used to manipulate them, and so that they are readable using ordinary text editors.
It may be necessary to have some HTML or script at the top and bottom of the wiki text files, but the amount should be minimized.
(Alternatively, it might be acceptable to have the wiki text files be largely HTML. However, in my community a large number of people are willing to deal with text files and not HTML.)
MikeHaertel? has suggested an alternative to placing the scripting overhead in each wiki text file. Instead, in each directory create an index.html file that has the ugly stuff that the scripts require; let this browse the directory, and format the text-only with minimal extra stuff that is in the wiki text files.
I think the obvious problem with this discussion is the mixing of content with markup implementation. That is, the content is message a user wants to read, not the markup; How the content is presented is (or should be) upto the tool/program used to present the content to the user. For plain text with minimal to no wiki markup, it should look like what we write to Mom in an text-editor. We don't use <html> in that case. Maybe there are stars for emphasis, or slashes for naming a movie, but tht's just about it; list points... -- IdKnow
Scripting
The wiki text files probably need to start a script running when visited. Likely candidates include:
In my experience, JavaScript is more ubiquitous than Java, so it will probably be the scripting LanguageOfChoice, even though I prefer Java.Since, most of the time, these would be running in a page accessed via a file URL, it is not clear whether they are server or client side. (However, it might also be nice to be able to serve these pages via a Web server. In which case, formatting could be client or server side, but saving edited pages is server side.)
The basic functionality of the script attached to a wiki text page is to format the wiki text, including wiki links. This "view" script can invoke other scripts, such as edit and save.
Other scripts might be provided, such as scripts to perform CVS checkin and checkout.
FilesystemBasedWiki wiki links
FilesystemBasedWiki wiki links would be interpreted as paths relative to the directory containing the page displayed.
Links would be WikiWords and possibly [[non wiki word links using double bracket syntax]].
The usual extensions for embedded URLs.
A FilesystemBasedWiki might interact with a CvsBasedWiki.
It might provide the scripts to format wiki text stored in the CVS repository.
Note: a FilesystemBasedWiki with CVS checkin and checkout differs from a CvsBasedWiki that provides wiki formatting for pages in a CVS repository viewed via CvsWeb. FilesystemBasedWiki view the filesystem, which may be a particular version checked out from the version control repository, or which may contain stuff not in the repository; CvsBasedWiki views the repository.
installing more software
The whole point here is I don't want to install more software.
If I could install more software, then there's many paths I could take:
But there *is* a place to do the wikicode->HTML conversion: in JavaScript (or JavaLanguage). Many web pages use JavaScript to make menus look prettier -- I don't have to manually install anything on my PC to get that functionality -- and it works even if that file is on one of the dozens of "free web servers" that don't allow me to install any new software on web server. ItJustWorks.
Far more people are willing to "turn on JavaScript" (or even "turn on Java") to view my content than are willing to "install this plug-in" or "install emacs" to view my content.
Far more web hosts are willing for me to upload ".html" files and ".js" files and ".class" files than are willing to "install a new CGI script".
The JavaScript would be in a single file in the same directory as the other files. Let's call it the "wiki_stuff.js" file.
The SimplestThing would be to add a couple of lines to the top of the other files -- something like
//<script type="text/javascript" src="wiki_stuff.js" ></script>
at the beginning of the file, and
//<script type="text/javascript">convert_wikicode_to_html()</script>
at the end.
. (I suspect that JavaScript can programmatically read in ordinary text files using "hidden frame" trickery, but let's stick with the SimplestThing First, OK ?)
These "special files" could link to any URI, whether or not that URI had this particular JavaScript written into it or not.
I'm starting to think we're arguing over the word "installed".
To me, there's a big difference between (a) "uploading a bunch of .html files ... and a .js file" (perhaps one could say this is technically "installing", but whatever you call it, it's a lot easier than these other 2 options) vs. (b) "uploading a bunch of .html files ... and asking the guy who mantains the web server to give execute priveleges to a new cgi-bin program that runs on the file server" ("installing a new program on the file server") vs. (c) "uploading a bunch of .html files ... and a .exe file", and asking all my users to download and run that program ("asking them to install this program on their local computers").
-- DavidCary
You may find a suitable wiki implementation over on WikiEngines. In particular, PhlIps GraphWiki is a Ruby implementation based on text files, and supports embedded GraphViz Dot code.
Doesn't look like it. Fails my ubiquity test - see WhatIsUbiquity. Ruby is not ubiquitous - portable, but not ubiquitous. I had been hoping that a wiki could be written in JavaScript, but apparently it cannot be, without external script support, and I don't know of a ubiquitous external scripting language. Java would probably be sufficient - but Java fails my ubiquity test too. Many of the people I want to reach out to don't have Java installed. See ProblemsWithFilesystemBasedWiki.
There are plenty of plain text file wikis. E.g. I am using TWiki. But they are all WebServerBasedWikis?.
While FilesystemBasedWiki appears to be hard to do, at least in a way that runs on both Windows and Linux, a CvsBasedWiki, e.g. one based on CvsWeb, appears reasonable, since, essentially, there's a server involved.
-- AndyGlew
How is a file system based wiki different from a shared file system? What does it do beyond letting people edit and view text?
It's as different from a shared filesystem as a wiki is different from a text file. The real question is:
[How is a file system based wiki different from a shared file system seen through Emacs running in WikiMode?] No difference. Except I want to do it without installing any new software. Web browsers are already on practically everyone's computer; Emacs is not.
OK, how is a wiki page different from a text file? I don't understand what a file system based wiki would look like. I can edit wiki pages. Other folks can read them. The same behaviors are possible on any shared file system. What else does it take to be a wiki?
Automatic cross-linking of pages. If the reader has to actually manually open each page that corresponds with a link, the system passes the threshold of non-usability.
So there's some client that navigates links, but this isn't hypertext? It sure sounds like hypertext.
It is hypertext. People are using their favorite web browser(s). I just don't want to set up a web server.
Let's see. You want:
The constraint that's really holding you back is #2. If you could relax that one, then you could check out your CVS tree into a subdirectory of your local Web space. Your wiki files would be editable through any Web browser, you could build your project in place, and everyone would be happy. You'd have to put a Web server and some language (e.g., Perl) on each machine, but that isn't much work if you're only using a few machines. How many machines do you want to have this capability?
If security worries prevent you from running a Web server, you can install one and set permissions such that only requests from the local machine are allowed.
The constraint that's really holding you back is #2. Or #4/5. How is this different from a HyperCard stack?
I think it might be interesting to do the wiki->HTML conversion in JavaScript.
The source of each HTML page would include reference to an external ".js" javascript file, <script type="text/javascript" src="wiki_to_html.js"> </script> plus a bunch of raw WikiText? (Embedded in JavaScript strings ? Or can JavaScript access the contents of <-! HTML comments --> ? ). When opened in a browser, the JavaScript code would hide all the raw WikiText?, do wiki->HTML conversion, and display the pretty HTML stuff. The JavaScript would also generate an appropriate header and footer. (it could also display another copy of the raw WikiText? in an editable textarea at the bottom of the page).
When the WikiText? includes a link to another file
CheesePizza or [cheese_pizza], the JavaScript would expand it to
<a href="cheese_pizza.html">cheese pizza</a>. (It seems impossible for that JavaScript to distinguish between pages that exist, vs. pages that do not exist -- but that's a minor problem).
If he allows a CVS Server, he probably allows an arbitrary NFS-Server too. The he could do without the WebServer, with the following scheme: The CVS-Directory with the files is imported (read) by a custom implementation of the NFS-Server, which does the Wiki-HTML Transformation. The transformed result is thus available as a filesystem again and can be read with any editor or browser. (If you dont allow NFS s/NFS/Samba/)
Would EddiesWiki be at least a start in what you are trying for here? It is not a Web server in the general sense, but supports HTTP requests and stores wiki pages in flat files. I use it on my machine to store arbitrary information in a manner that I will never forget how to access (as long as Web browsers are ubiquitous) and is very easy to modify.
There's only one problem with EddiesWiki in this respect - it's (at least presently) Win32-only. There's very little in it that is Windows-specific, however; has anyone ever tried compiling it for Linux? -- MikeSmith
Not anymore win32 only. See http://www.wikiserver.org for more.
Interesting topic to look at is http://twiki.org/cgi-bin/view/Codev/DataBaseLikeFileSystem -- Zeljko Blace
Is infocetera (http://www.infocetera.com) (BrokenLink 2004-11-11) what you want? It is directory based and works with tcl/tk. I use it on my machine as a kind of PIM. Have a look ...
-- Jeroen
static web pages
(moved to StaticHtml)
File-system-view based wiki
For some time I have been looking for a Content Management System (CMS) which just gives a view of a file system.
(moved from WikiHelpDesk)
Q: Most wiki software I've used so far (this site and WikiPedia) use the CGI software for both editing and display (ie, looking up articles).
It seems to me that one could make a wiki that included the "edit this page" as a link through the cgi, but whose articles are stored as HTML text in a directory - like any normal static site. This would be the best of both worlds, all the flexibility and editability of the wiki world, but all of the speed, mindshare and simplicity of a normal web site.
Is there such a wiki?
Do you mean a wiki that saves its pages as both HTML and wiki format, serving the static HTML version for viewing and the wiki format for editing? If so, links in the static HTML could become stale. For example, what happens to a page's link to FooBar when FooBar is deleted? Until the page is edited, the link will indicate FooBar still exists. Alternatively, any time a page is added or deleted you could check every static HTML page and rewrite those that have links to the added/deleted page, but that might slow down the wiki.
TiddlyWiki looks like a solution for filesystembasedWiki. It is one HTML file with javascript included. The only thing is, it is not 100% wiki. -- Jroeterd
Are "Web Hosted Editors" http://texteditors.classichorseman.com/cgi-bin/wiki.pl?WebHostedEditors somehow related? ( BrokenLink 20120603 )
The "web pie masher" http://pie.ekkaia.org/ is a WikiEngine (?) that "refrains from interpreting page sources at run-time at all. Instead, it compiles your page once you enter it, furthermore just conveying the precompiled output to the reader."
One day browsers will read directly .wiki pages, maybe with a tag at the beginning (<wiki link_type="camelcase"> or something). you'll be able to write an index.wiki file and it will open and show up perfectly. -- Frank
This discussion is interesting to me because it seems we are aiming at a similar target. Here is my fantasy:
Imagine Windows explorer (WE). It has the ability to open folders as windows on your screen. In the window you see a list of files. You can also have a background image in the window with a little extra effort. The files may be shown as icons or text. WE stops there, but what if it had a few more features?
-- Ian
EditText of this page
(last edited June 3, 2012)
or FindPage with title or text search