So, I've put some more work into my S3 AJAX wiki, first mentioned Friday night. After some Virtual PC sessions, editing seems to be working on Firefox and MSIE on Win. Safari and any other browsers not amenable to PUT and DELETE in XmlHTTPRequests will not find joy in editing - but the wiki should at least still be navigable and readable since it's plain HTML on the server.

This thing has certainly not reached any level of stability, but I thought it might be interesting to collect some random thoughts on what good stuff is lurking in there. So:

• One of the mind-bending concepts behind this whole thing for me is that both the documents and the authoring application are all resident on the S3 servers, loaded and run on the fly in a browser. The magic S3 lends is simple file I/O, taken for granted by applications in nearly every other development environment. Otherwise, JavaScript in a browser is a very capable system.
• Of course, since my demo wiki is sitting in an S3 bucket with a public-write ACL, everything's open to vandalism and subversion (of the bad variety)- documents and application both. S3Ajax does allow authentication through your S3 credentials, though, so a private group with restrictive S3 ACLs could use this wiki successfully.
• All content managed by the wiki code ends up as HTML on the server. Maybe some day this will grow up to be proper XHTML. Using plain old HTML, rather than smart ASCII, seems like an important step to me. HTML is a neutral standard, whereas various wiki formats are far from agreed upon or standardized. Luckily, Stefan Gössner's Wiky does roundtrip conversion between wiki-text and HTML.
• Sticking with HTML as the end format also allows me to eventually go beyond wiki text, and on to microformats like hCalendar and XOXO. I could even see interchangably using something like DOJO's Rich Text Editor as another editing alternative alongside Wiky. Basically, anything that eats and emits HTML can fit into this wiki.
• One more thought on HTML and the DOM - if you can use HTML as your document format, the browser DOM makes a pretty nice structure and API for the authoring, manipulation, and management of document content. In this wiki, innerHTML is the main point of document munging. But, in XoxoOutliner, I do plenty of DOM node shuffling and tweaking.
• Speaking of innerHTML: It's not evil, but it seems useful really only when treated as a write-only property. It's next to useless for serializing the DOM as HTML source. MSIE and Firefox both offer wildly different results. So, I wrote fromDOMtoHTML in wiki.js to take matters into my own hands. I know MochiKit offers emitHTML, but it doesn't quite do what I want - there are a few odd corner cases I've found myself handling, and I need to filter out all the elements I inject as editing chrome.
• I like the functional DOM construction kit offered by MochiKit and DOM Builder so much that I felt compelled to reinvent my own. Check out createDOM in common.js. I use it in the injectEditingFramework function in wiki.js to build and inject all the wiki editing chrome into the page on the fly. I re-wrote this code so as to not import the bulk of MochiKit, but before I'd heard of DOM Builder. I'm keeping it around for now.
• Speaking of reinventing things, check out xmlToObj in S3Ajax.js. I hadn't seen BadgerFish until about an hour ago, but xmlToObj is my own simplied version: That is, code to turn XML into basic native JS structures. I use this to easily deal with the XML response from S3 bucket listings. It works better than I thought it would.
• Speaking of xmlToObj, I use an S3 bucket listing with a key prefix to populate a "recent changes" drop down selector, sorted in reverse chronological order of the LastModified timestamp.
• And speaking of bucket listings: I don't use them in finding existing wiki words - but I may do so in a future version. But, instead, I got fancy and perform a number of HEAD requests to determine which WikiWords on the page do and don't exist. I do this with chained AJAX calls - the completion of each fires off the next HEAD until I run out of words to check. The discovery of non-existent pages linked by wiki word triggers a CSS class change to highlight the word in need of authoring, as well as the attachment of an on-click handler that causes the creation of a new page for that word.
• In the future, I'd like to use the Atom Publishing Protocol, as well as the OPML Community Server Protocol (via XML-RPC). If any other AJAX-accessible web file systems crop up (GDrive?), I might hit them too. I'm considering WebDAV, trying to decide if it's worth it.
• All-in-all, I think where I'm going with this stuff is basically what I wanted to do with Micronian.
• OPML is another format I plan to explore with this rig, very soon.
• I'd love it if someday I could use all of this stuff to research, plan, organize, and write a book.