As Yaki starts shaping up and becoming usable, I've been mulling a number of things that range from the way I want to migrate this site's content (and the code to do so, which I am reviewing today) to the way I want to edit content in the future.
One of the things I've also been investigating are weblogging APIs and editors, for the simple reason that no matter how simple Wiki markup (or Textile, or Markdown) tends to be, I'm getting a bit annoyed with drafting posts in plaintext.
Writing is a matter of flow, and you lose track of flow (and sentence length, which is crucial for readability) when you have to deal with markup and have URLs strewn all over your copy.
And since I'm designing Yaki to convert everything to HTML internally, it makes sense to have some form of WYSIWYG editing regardless of how much more flexible it is to just open TextMate on a plaintext file and go at it.
So far, I've singled out three main options to go WYSIWYG:
- Stick it out until there are decent browser-based options that work on Safari.
- Use a weblog editor such as ecto or Qumana.
- Do my own thing.
The first one is one of those things there is no real solution for due to different browser implementations and other hassles. Right now it boils down to either using a Flash-based editor (which actually seems sensible) or wait until WebKit/Safari does it properly.
But either way it doesn't allow for offline editing, which is a pain.
The second one is, quite frankly, a mess. There are entirely too many weblogging APIs, I don't want to code for any of them (all of them are potential security problems and bog down web servers), none of them was designed to deal with the peculiarities of a Wiki, and they all (both APIs and editors) make a mess out of image handling and uploading.
You see, to me, images have to be an integral part of a Wiki node/post and not something else you toss into a folder and refer to. I hate having a media folder full of random, non-contextual images and other crap.
The Third Way
So I'm going to do my own thing. And a couple of weeks ago, I decided that I would start taking a serious look at Mind Maps again. The reason being that, with work taking up a lot of my time again, I needed a way to jot down my personal notes and keep it all together, and my two current alternatives (using VoodooPad or drafts stored on my IMAP account) weren't cutting it.
Using VoodooPad is great, mind you. The "lite" edition has been much more than enough for me for years now, and a bazillion of this site's nodes were drafted on it. But it lacks a visual index of some sort, and about 9 months ago I took a long hard look at the new file format and decided it wouldn't fly for me as far as sharing files are concerned.
Because, you see, I split my writing across my desktop and my laptop, and needed a simple way to sync drafts between them - and VoodooPad started coming up short then.
By now I was using Mail.app as a blog editor. And I got it working to a point where I would save stuff on my IMAP server's drafts folder, pick it up again on another machine, and have a little Python script automatically strip away all the Mail.app formatting gunk and give me a nice text field I could just copy and paste into this Wiki, or have a little script fetch stuff from an IMAP server and add it to Yaki.
And regarding syncing between my laptop and desktop, that was more than enough.
The trouble was that Mail.app's editing abilities are limited to say the least (for one thing, it doesn't do HTML bulleted lists, which is tremendously irritating).
Butterflies and Lightbulbs
So I started looking at FreeMind. I already use it copiously to take notes, but not as far as actually drafting posts on it. And looking at it in that context, it has the following pluses:
- It allows me to quickly jot down stuff I want to write about later (or even draft entire loose paragraphs) and tie them all together visually (which is always the best way to find stuff).
- It also has a working HTML editor for adding notes to nodes, so I could theoretically write complete posts inside it if the editor was ever so slightly better implemented.
- My "Notes" mind map is a single XML file, which I can drop into my .Mac iDisk and forget about.
- FreeMind can be scripted with Groovy (something I'm not really that keen on exploring, but which might yield some interesting use cases), so I might conceivably post stuff directly from it.
I would vastly prefer Jython (which was thrown out because the initial versions were slow and possibly due to a bit too much Java-centrism on the part of the developers), but lacking that I can always grab BeautifulSoup and parse the mind map itself.
Then again, FreeMind also has quite a few minuses:
- The FreeMind community tends to spend more time bickering about the app's logo (i.e., whether it ought to be a butterfly or a lightbulb) than discussing features and improvements.
- Their Mac versions always have some niggling shortcomings when compared to Windows ones, even though there are a few knowledgeable Java/Mac coders in there somewhere. And they insist on using .mm as a file extension, which causes all manner of trouble with Xcode (no, they don't set the creator type on the files).
- FreeMind's HTML editor, for some reason, doesn't have a quick and easy way to insert links in the HTML source - even if I currently can draft most of my stuff in Wiki markup, I'd much rather do it in a WYSIWYG HTML editor and filter it to Wiki markup or post it straight as HTML, and not having links is a pain.
- .Mac's iDisk, despite all the grumbling on the Internet, is still no speed daemon, and last time I checked it wasn't all that secure, running all transactions unencrypted over standard HTTP. Not that what I write won't become public, but I'd feel a lot better if iDisk used SSL.
The WYSIWYG Bird
So I went back to looking at IMAP, and beyond Mail.app's obtuse pseudo-HTML editing. Correo is nice and lean but can't do any sort of HTML formatting yet, so I fired up Thunderbird and had a long, hard look at its HTML editing abilities.
And it turns out that it's pretty damn good - not only can I edit (and position) images, do bulleted and ordered lists and insert blockquotes, etc., it can even do tables in a (somewhat) sensible fashion, and the generated markup looks pretty clean.
Better still, images are saved (and sent) as MIME attachments in drafts, which means that I can theoretically "upload" an entire post (text, images, warts and all) in one fell swoop.
Yes, richer media such as Flash and video is tougher, but I can live without that for the most part.
Furthermore, Thunderbird is as cross-platform as it gets, and parsing MIME messages is a trivial endeavour in Python (I've done it umpteen times before).
So it seems like the way to go right now. There's also SeaMonkey (which has a vastly superior HTML composer), but I draw the line at having to stare at Netscape-era UIs.
Finally, a Use for the Usenet Protocol
As to the "upload" protocol, well... That's another thing. IMAP is entirely too complex to implement on the server side, so I can't possibly edit my Wiki by virtualizing it as a set of folders on an IMAP server.
But setting up an IMAP server as intermediate storage and have Yaki poll specific folders is entirely doable, as is hacking in a very simple SMTP server to accept incoming messages, parse them and adding them to the Wiki storage (been there, done that already for other projects besides Yaki).
So I was looking at Thunderbird's settings panel, and it hit me that I could try using... wait for it... NNTP.
Yep, NNTP. It does everything: posting, search, retrieval, the works. People have been uploading all sorts of junk straight from their machines (for what, decades now?) and, coupling that with Thunderbird's HTML editing, I would be able to do the same for entire articles, complete with inline images.
And yes, I am aware that it is profoundly evil to post HTML content on public NNTP servers, but in this case... It would be wicked cool to view my Wiki (or only the blog portion of it) as an NNTP tree.
I could probably use the wonderful papercut as a starting point, and (after some hacking) also gain a nice bonus - a potentially simple way to replicate content across Yaki instances.
Damn, I need a month's vacation to have time to code this...