The area that struck me as most important was the relationship between nodes. From simple linking via "[ ]" to direct parent<->children associations, I saw a method that seemed natural to the way we (humans) organize information.

Because isn't that what it's all about? The organization of information in such a way that it's non-obtrusive yet accessible? The raw storage of information is no longer difficult, mining it for specifics is.

I finished my first noding system about three months ago. It was an emulated Everything2. I copied all the features and expanded on them; but kept the basic storage and association of nodes similar.

It was good. Certainly as good as E2 (at least in functionality. It was, of course, no where’s NEAR as mature as Everything but that would come in time), but wasn't expansive and generic enough for me. I then started writing what I now call my Generic Noding System, or GNS.

The absolute, core concept of GNS is total ignorance of the contents of nodes. They can be any sort of data; the modules that handle the nodes rarely peek into the body. The nodes can be text nodes (as with E2), binary nodes (images, MP3's) and many other types. The second-place core concept is ignorance of the client application. I wanted GNS::Node to not care if the client was a browser, or a telnet app. The application that utilizes GNS::Node would do all that work. With this method, I had hoped to write HTTP, console, mail (yes!), ICQ and any other interface I could think of.

I implemented this abstraction with two fields in my nodes, "type" and "mimetype". "Type" defines the basic behavior of the node. If the node handler finds a type it is not familiar with (application-level extension), it has a default behavior it can use.

"Mimetype" is nothing more than a HINT to the user app of how to display the contents of this node. This is the output type of the node. Of course, in my current implementation the mimetype is almost always "text/html"; though the system supports anything.

The basic types I have are: text, perl, url, file, home, chat and link.

• text

  your standard node. The contents of the body are passed to the user application as-is.

• perl

  the node body is actually a perl script to be "eval"ed (IO::Scalar!).

• url

  the body is a URL. When the node body is retrieved, that URL is fetched (ala LWP::Simple) and returned AS the body of the node (in the same way the output from the perl type is returned as the body).

• file

  this is a file reference. The body is a fullpath to another file. When the body of this node is returned, the contents of the file are returned (and I use a function call to return the node body in chunks in case this is a multi-megabyte file).

• home

  A homenode. The only reason this has it's own type is that a user's homenode is found by searching for a node owned by the user and whose type is "home".

• chat

  for the implementation of a chat system (a user application that utilizes GNS::Node for a chat room -- rooms are parent nodes, replies are children). Nodes with the type of "chat" are excluded from various operations (like searching). Additionally, chat nodes utilize the "expires" field available in any node. The expires field gives the number of seconds after the node's creation (or modification) that the node self-destructs.

• link

  this is a symlink to another node. When this node's body is resolved, the contents of the linked-to node is returned instead.

---

Now, one of the issues I was (and still are) having when writing this was keeping my application-level program up to date with the functionality of the modules (after all, I am writing the CLASS for this, not the user-level application). There were SO MANY good functionality-side-effects of my design that the interface I was writing (html.cgi) couldn't keep up.

For example, there is "full screen" mode which when you do on a binary node returns the node as if you were downloading a file of that type from the web.

And then there's the chat room. When you reply to a node, you copy it's basic fields. So, if a chat room is a collection of nodes and subnodes, I found you opened a subnode as the main chat room, you created a sub thread of conversation. (You have to see it to understand :). And if you did that on a private chat node, you created a permanent, private chat room between yourself and the other person.

But since you can change the type of node when you reply, you could add different types of nodes to threads (replying to a request for a URL by providing a node that IS the contents of the URL, etc..)

All the side effects have yet to be found and it breaks easily :)

But I invite you all to look at it anyway. I'm not ready to show the code yet as it's still under great flux, but I can show off some of the basic features available.

I can't provide a public Perlmonks account because my security on executing nodes is practically nil. I will take personal requests for accounts however.

So, head over to www.binary9.net/noding and check it out. You will be nobody but that's OK. Oh, and I've only looked at the system through Internet Explorer, so YMMV.