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.

Archived Comments

  • Why did you break down DOM Builder into two functions and an initialization call?

  • Bill: Well, mostly because that code was an attempt to recreate Mochikit's DOM construction code apart from all the other facilities it uses to build functions with partially applied argument lists & etc. I hadn't actually heard of DOM Builder when I first wrote that stuff. I'll probably swap my code out for that at some point.

  • This is a very impressive web application foreshadowing the high potential of online storages.

    I like the way, how you reuse and extend Wiky.

  • Okay, I know I keep telling you to check out Ning, but with the new API stuff we released last week you really really need to check out Ning. It meshes remarkbly well with what you're looking for.

    The new API is fully read-write, based on REST and the Atom Publishing Protocol. Other advantages over S3:

    • Each app has 1GB of public object space and 100MB of private space. Each user can own up to 10 apps for free. Just register, clone an app (or make one from scratch) and you're off.
    • With S3 the objects you read and store are flat data - with Ning, they're structured objects...
    • ... and since they're structured, you can issue GET requests that are more like database queries than simple object fetches (some examples)...
    • ... which return properly-formed Atom feeds, which you can then run through BadgerFish. (it's how our demo widgets work)

    That's not to say that S3 doesn't have it's own advantages: it's much better for large (GBs), expandable storage, five-nines high availability and BitTorrent. But the uses to which I'm currently seeing it put - such as your work, and the Greasemonkey ideas - fit Ning very well indeed.

  • Are there any alternatives out there to innerHTML that are just as easy-to-use, but that actually make use of the standard DOM methods instead? (Please say yes.)

  • Bob: Alas, no. The best I can come up with is to maybe run a string containing a document fragment through an XML parser, scoop up the resulting nodes, and transplant them into the page DOM. I haven't tried that yet, but the idea smells awfully bad to me.

    innerHTML isn't really that evil, really. :)

  • Is the new Google Data API a possible alternative?

  • Bill: It looks like the new Gdata API is basically the Atom Publishing Protocol. I'd like to target that API sometime soon, too. I think Ning's got it implemented as well. Although, at Google, I think the only implementation of Gdata so far is for the new Google Calendar - that is, I haven't seen any Gdrive service launched yet as a generic service offering storage via Gdata to compete with S3.

  • Hi, I'd like to search my documents stored in my s3 account. It seems like Amazon doesn't provide a search API. But maybe we could add this functionality. Any idea if somebody is already working on this? Laurent. Palo Alto, CA