File 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 * No need for internal preview, use a standard browser, e.g. firefox, to view converted html page; * Support all correct html tags, or just pass them intact into converted html pages. Is that possible? -- AndyGlew (did Andy write the previous paragraphs or the following? I moved the four hyphens to the next line) ---- 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 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: * JavaScript * JavaLanguage 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 WikiWord''''''s and possibly [[non wiki word links using double bracket syntax]]. The usual extensions for embedded URLs. '''FilesystemBasedWiki''' 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. * I have a bunch of files on my local filesystem. * I want to view them, and click on links to jump between them. -- I can do this with the web browser already installed. * I want to edit them. -- I can do this with the text editor already installed. * I don't want to type HTML. I want to use a simpler wiki-style markup. * I don't want to install any more software. * I want it to work on Windows and on Unix. Is it really impossible to do this ? If I could install more software, then there's many paths I could take: * Install Emacs, and use WikiMode. * Install a web server, and one of dozens of WikiEngines. * Install Python, and use PythonServerPlus and one of the Python WikiEngines. * Install EddiesWiki Another alternative: learn HTML. * LearningHtmlAndCss ''This is explained below, where someone observes that there's nowhere to do the file->html conversion, but let me ask it another way. You seem to be asking to add capability to your computer, but without adding software. I can't see how that's possible, so clearly I'm not understanding what you want.'' 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". * But where is the JavaScript? If you are simply browsing files on the machine then they don't have JavaScript in them. Are you suggesting that you can't browse ordinary files, but can only browser special files that have JavaScript written into them? ---- ** When I read the above line the first time, my instant thought was about the binary, not the loadable code referred to by an html page. Javascript is now (2011) available as a separate, runnable binary as Node.js; it doesn't need a browser to run!!! Might this be an elegant solution to running PersonalWiki? ---- 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 // at the beginning of the file, and // 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. * But now you have installed more software. Specifically, you have installed a program written in JavaScript. I could give you a single executable to put in a directory that acts like a wiki. Just as the JavaScript file "wiki_stuff.js" you envisage, this would be a single file that you put in the directory. Would you accept that? Yes, that would be great. 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, PhlIp''''''s 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: 0 to run a wiki 0 not to use a Web server 0 something that works across all platforms 0 pages viewable/editable using a stock Web browser 0 not to rely on any browser plugins (e.g., JavaLanguage) 0 raw pages stored as individual text files 0 raw pages editable using standard text editors 0 basic wiki markup -- WikiWord''''''s at a minimum 0 files to live within a CVS tree (for a WikiForLiterateProgramming) The problem is that you don't have a place to do the wiki->HTML conversion. Without a Web server, the only place to do the conversion is the browser. You can't write a wiki plugin and you can't do it with Java, which leaves JavaScript. However, you want the text files to be editable with standard text editors, which makes JavaScript a poor choice (too easy to accidentally mess up). Also, there's no guarantee that people using this system have JavaScript enabled in their browser. 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, 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 Cheese''''''Pizza or [cheese_pizza] , the JavaScript would expand it to cheese pizza . (It seems impossible for that JavaScript to distinguish between pages that exist, vs. pages that do not exist -- but that's a minor problem). ** javascript doesn't distinguish between pages that exist and those that do not, that's a browser or HttpProtocol function. -- IdKnow. But then: * How does the edited text get saved back to the filesystem ? Isn't JavaScript specifically prohibited from doing that ? ** That would be done by HttpProtocol#Post or HttpProtocol#Put. -- IdKnow. -- DavidCary ---- 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. * This could be simply a Windows-like File-Explorer applet available in a browser. The files being browsed are html. Then when the user clicks on a file it is displayed. * Put another way: clicking on a leaf on the file-system tree displays that page to the user. * The surrounding borders to the displayed page could provide for a wiki-like "edit" button, with a banner showing the current directory path to the current page. * This engine would be great for providing an alternate view onto existing web sites. Just by viewing the site's file structure. * It is essentially a souped-up version of the file-view provided by all browsers when given a directory as the URL. ---- (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 Foo''''''Bar when Foo''''''Bar is deleted? Until the page is edited, the link will indicate Foo''''''Bar 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 ( 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? 1. The file descriptions shown in the window could be moved anywhere in the page, and could also be the argument to wikiwords. Ah! Now the window looks like a wiki page. 2. We can type text anywhere in the window where it stays until we change it or move it. 3. Media can be inserted into the page. It can be moved and resized and/or thumbnailed. 4. Wikified links can be entered that will invoke other WE folders. That is to say, now WE has wiki hyperlinked functionality. 5. Applications may be started from within the WE window. 6. The filesystem list within the window can be "boxed" in a container that can be resized, iconified, and dragged around. 7. Tags may be assigned to WE windows so that a list of windows may be invoked relative to any tag. This mechanism, plus the wikiword hyperlinks, gives us the sort of organization we expect from a wiki. I have used a tiddlywiki (TW) for several years now. It serves to organize my life. Inside my TW I can browse the web, view the filesystem and launch applications. The personal wiki, of whatever breed, is the next step in user environments. But as of now it runs in a browser. I envision the wiki as THE operating environment of the PC. So should it be a file manager? Should it be a window manager? Clearly the Linux kernel can run underneath it, so there is no need to re-invent an OS. -- Ian ---- See TaggedDatabase JavaScriptEnabledWiki TiddlyWiki CategoryWikiImplementation