One significant advantage a more conventional outline has over the
outline structure I've built up here is that it is much easier to
store the traditional outline in a file. Using XML, traditional
outlines are almost trivial to store:
<node text="A"> <node text="B" /> <node text="C" attribute="D" /> </node>
I just had pretty much the worst week ever at work, which accounts for
my not posting anything this week. How bad? I just finally noticed
today that I didn't post my Monday Iron Lute post.
I can only hope this week is better. Unfortunately, it doesn't show
any particular signs of improving, so posts may be slowed up this week
This week instead of continuing on with my outline series of posts,
I think I may jump ahead and discuss the file format for my outline
model, which is what I'm working on right now. Designing a file format
to hold the data hasn't been too hard, but it's been a bit of a brain
bender trying to figure out the best way to implement it. There
are a few interesting things you can do with an outline structure you
can't do with a conventional flat file, and I want to make sure that
those things are possible. What day this will get posted, I don't
know, since I still have to write it.
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 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 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
If nobody uses it and nobody helps me with it, then eventually,
I'll stop supporting it. (No surprise there.) I'll keep it online and
quite possibly continue using it in my own personal projects, but
unless somebody else shows an interest, no public sign of development
(Truthfully, call me arrogant but I do not consider this likely. I
think there's a definate niche in the Open Source world for what I am
creating here, partially because of the lack of an outlining widget
that I mentioned in my original post.)
If I get significant contributions from other developers and other
people (including documentation, help, community helping each other
out a lot, etc.), I'll make it the aforementioned limited GPL. The
threshold for this is "if I had to remove all contributions other then
mine to date, how painful would that be?" If it can be done swiftly
and painlessly, then I may go to the third option.
The third option is "a lot of people use it and like it, but nobody
is helping with the development". In that case I'll do an analysis,
and either stop development, or try to take it commercial, depending
I'm thinking of a cut-off date of a year after the initial "stable"
release, which would be some months after the first public release, of
course, so we're talking about at least a year and a half window,
I'd like to say up front that I want this to be open
source. I want to experience new features of Iron Lute that I didn't
have to write myself. However, I do not want to tie my hands by
committing to a license "come hell or high water"; the condition above
is not intended as a "loophole I can jump through" so much as a way of
pointing out that two pages of docs and a node type do not
constitute "significant contributions" in the sense I am
mentioning. Believe me, I will err on the side of "open source" if
anybody gives me the chance.
So, what license this is released under is at least partially up to
I will make this commitment though: I will not pull the rug out
from underneath you. Should I end up going commercial, the last "free"
version will be clearly marked, never crippled, and will never
expire. You just won't get updates and improvements.
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
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.