In my last post, I dissociated the concept of "outlineness" from a graph, and showed at least the skeleton of a data structure that allows the power of graphs while preserving the nature of an outline.
In this post, we will fix a flaw in the model built up to that point, which is that there is no way to obtain a list of parents, given a node, only a list of children. For various reasons, this is necessary to building an outliner, so this flaw must be fixed.
Rand Anderson's (update: sorry about the misspelling!) previously-mentioned blog post brought his Executable Abstractions weblog to my attention, and I noticed something interesting about it; namely, that while it was obviously a generated weblog it didn't match the profiles of any of the many blogging systems I am already familiar with.
A little digging on the homepage led me to PyDS, which is basically Radio Userland in Python. (Not Frontier; the aspects that Radio Userland added to Frontier, the News Aggregator, the Weblog, Tools, nice Preferences screen, etc.)
Rand Anderson blogs about Iron Lute and his preferred outliner Leo:
Seems he's aware of Leo (my outliner of choice) but wants an outliner that allows the use of the outline structure for all content (as opposed to having a body for free text associated with each tree node, as Leo does).I'm pretty committed to Leo and it's author's vision for Leo going forward, but Iron Lute is worth keeping an eye on.
I want to be able to discuss Iron Lute's planned license in a posting in response to somebody's blog here, but first I need to discuss it. So here are the licensing plans I have for Iron Lute. I'm very interested in feedback on this.
I'd would like Iron Lute to be open source, likely GPL with explicit exclusion of plug-ins (i.e., you are explicitly allowed to create new Node Types, etc., and release them under any license you like). (This is not quite the LGPL because you still can not take Iron Lute and build another application around it; limiting as I will means you can "connect" Iron Lute to your application but that you can not just pick up Iron Lute and make it be your application.) But that depends on the usage and support pattern it receives.
In my previous post, I concentrated on extending our data model to handle multiple data sources cleanly and transparently. However, we now have a conceptual contradiction in our data model. To this point, the data model we've built still assumes it is a tree, which means we can use the tree-optimized algorithms for things like counting children. But if a document transcludes something that transcludes the original, we can have a cycle, which means there is a path starting with a node in the original, going through the transcluded document, and ending up back at the original node. Most tree-based algorithms respond to this situation by infinitely looping, which manifests itself as a hard lock-up, which is generally considered a negative by users.
In my previous post, I discussed what I believe is the outline data structure in current use by outliners, and why they are inadequate for my purposes. I discussed why transclusion doesn't work very well under that model (an algorithm can sort of hack transclusion on top of the tree, but it's not "real" enough), and the difficulties of replacing some of the tree concepts when you have a full graph. Today's post covers the "transclusion" issue.
It happens to me without fail.
I have three computers in this house. One is a headless machine that runs Radio Userland, providing my news aggregator and this weblog, and nothing else. One is a Linux desktop machine that Windows literally refuses to run on. One is a laptop that runs primarily Linux but has Windows only because it came that way. Thus, only two usuable machines.
Whenever I take one of the machines down for heavy duty maintenence, secure in the knowlege the other one can easily pick up the slack, BAM one of the hard drives in the other machine comes crashing down, taking down both of them at once.
All this week, I've been Joe-job'ed. It's in "response" to my insulting comments about spammer's intelligence here, here, and here, with regard to the article I wrote on Bayes Filters.
The efficacy of a Joe-Job has decreased significantly over the past couple of years. Ever since the Window viruses that starting forging return addresses willy-nilly, we've all been "joe jobbed" for the last few months. Going from 0 to 100 spam bounce messages a day would be much more annoying then going from 20 to 120 spam bounce messages.
As I hinted at in my previous post, this is not as easy to answer as you'd think. To give you a hint on how hard it is, I'm currently up to my fourth major version of my fundamental data structure. The best way to answer "What is an outline?" is probably to take you through the same development process I used to get to where I am now.
A word of warning: I'll try to keep this largely comprehensible to anyone who's willing to really try to read this, but (as some of the more technical of you are probably already guessing) we will have to dip a little bit into graph theory and some programming concepts.
I've been writing ahead on my promised developer travelogue posts, because I am trying to make them high quality posts useful for programmers both new and old, not just off-the-cuff reportings of what I happened to be doing last night.
I was concerned about the time lost writing these posts, because as I said, time spent writing is time not spent coding. (Though I'm getting much of the writing done when coding is not possible.) An entirely unexpected benefit has accrued, though: I was factoring out a concept from the next two posts and it has prompted a nearly complete re-conceptualization of how the dominant programming paradigms of our day inter-relate.