Before I discovered NetKernel, my physical library consisted of a copy (= immutable representation) of the LOTR books as well as everything Stephen King had written up to that point (I actually learned English from reading "The Tommyknockers" over and over again, so blame him if my English is far from perfect).
Since then countless books on mathematics have been added as well as a (treasured) copy of The Codebreakers (the 1967 edition), books on evolutionary biology, ... the list goes on and on ...
So I was rather pleased last week after reading the NetKernel newsletter that I could go back to the roots and read up on the Ents. For after all, trees need guardians don't they ?
Do I agree with what Peter says in the article ? Well, as a database administrator I've seen the demise of the hierarchical (tree) database, the coming and going of the network oriented (codasyl) database and the rise of the relational (codd) database. And just now the latter is under fire by the nosql/document database. And the funny thing is that a document is a tree, instead of there being something new we've actually come full circle.
So yes, he might have a point. And the Hierachical Data Structure brings this datastructure neatly to your code, because lets be frank, it is a pain if the datastructure in your code differs from the one on the database. Let us - for example - take a look at the active:fls accessor. It takes an IHDSNode as input :
<root>
<fls>
<root>file:/var/tmp</root>
<recursive/>
<filter>*.tmp</filter>
</fls>
</root>
Yes, I do know that is XML. It is just a representation, a way of viewing at HDS. Every IHDSNode has a root element which may be ignored for practical purposes. Incoming XML (for example) is transrepted into a tree underneath this element. On the way out the element is removed.
This will make it more clear :
root : null
fls : null
root : file:/var/tmp
recursive : null
filter : *.tmp
fls : null
root : file:/tmp
filter : *.bak
The above IHDSNode contains a forest, not just a single tree. Normally speaking you can not transrept this to an XML representation (an XML can not contain a forest). But the transreptor has foreseen this (border) case and turns it into :
<hds>
<fls>
<root>file:/var/tmp</root>
<recursive/>
<filter>*.tmp</filter>
</fls>
<fls>
<root>file:/tmp</root>
<recursive/>
<filter>*.bak</filter>
</fls>
</hds>
Whereas the original example transrepts to :
<fls>
<root>file:/var/tmp</root>
<recursive/>
<filter>*.tmp</filter>
</fls>
Since one has to be careful these days ... for the purpose of this blog entry I define a forest as a group of two or more trees.
Did you notice the similarity with JSON ? Here is another possible representation :
{ "fls" : null {
"root" : "file:/var/tmp",
"recursive": null,
"filter": "*.tmp"
},
"fls" : null {
"root" : "file:/tmp",
"filter" : "*.bak"
}
}
Do you see my point ? I could not care less when I read that XML is dead and that JSON Rules. For I guarantee it, before the year is out, somebody with clout will get tired of typing curly brackets and invent something new (and if nobody does, I will). Bullshit (forgive me my French) ! Debating representations is moot. We care about resources. And the Time of the Tree has arrived (once more) ! Check it (HDS) out !
For your information, here's the Groovy program I did my experiments with :
import org.netkernel.layer0.nkf.INKFResponse;
import org.netkernel.layer0.representation.IHDSNode;
import org.netkernel.layer0.representation.impl.HDSBuilder;
builder = new HDSBuilder()
builder.pushNode("fls",null);
builder.addNode("root","file:/var/tmp");
builder.addNode("recursive",null);
builder.addNode("filter","*.tmp");
builder.popNode();
builder.pushNode("fls",null);
builder.addNode("root","file:/tmp");
builder.addNode("filter","*.bak");
builder.popNode();
response = context.createResponseFrom(builder.getRoot());
response.setExpiry(INKFResponse.EXPIRY_ALWAYS);
That's it for this week ... O yes, for obvious reasons, Tom Bombadil is my favorite character in LOTR, but Treebeard does come in a close second.