@SpyderTL: are you familiar with
Project Xanadu and the concepts behind
xanalogical document storage? One of my primary goals in Kether is to implement xanalogical storage (independent of the current PX code base, but with the idea licensed from Nelson) rather than a file system.
For those unfamiliar with it - which will probably be the majority of those reading this - the idea is simple, but difficult to implement, and often poorly explained (including by Ted Nelson, sadly; while he's good at inspiring enthusiasm, he has a lot of trouble getting the idea across). From a technical perspective, the core of a xanalogical system is a collection of out-of-band internal hyperlinks to fragments of data, each of which holds the information about the source, creation date, size, ownership, visibility and format of the data fragment. Each document consists of several such links.
Sounds sort of like an i-node, right? Well, not really. You see, the data fragments do not form a
single document, but are independent of each other, and multiple links can point to a part of any given fragment. Documents in xanalogical storage are logical entities, not structural ones. There is no master directory of documents; rather, documents are built dynamically when requested, and any document can include and share something originally created in another document - a process called
transclusion - seamlessly to form a new document.
Data segments are stored permanently in a single (logical) address, and never permanently copied, though they may be mirrored for backup purposes, and may be temporarily copied to a LRU cache for remote access. Copies, whether permanent or temporary, have the same logical address as the original. Networked copies have the same visibility and publication status as the original, and can be served from any existing copy if it is more readily available than the original (such that if a request for a data segment is sent through the network, each system it passes through should check to see if a copy is held locally, and should short-circuit the fetch to use that copy rather than going on to the originating system).
When a document is created, the data in it is journaled, and periodically saved as a new data segment. When a data segment that has been already stored is edited, rather than changing the existing data segment, a new data segment is created with an alternate link to the new segment. This means that (to an extent) there is a record of significant changes to the document, and (among other things) continuous undo for changes.
The hyperlinks are not directly visible, as Web hyperlinks are, but rather are a means by which documents are structured and presented. Presentation of the links themselves is a front-end function, but in most cases they are a back-end entity. The links are bi-directional ('bi-visible' in Xanadu terms), meaning that the presentation software can (if it has permission to and is written to do so) allow the browsing user to follow the link back to the originating document.
I'm a bit short on time right now, but that should give some flavor for it. I can explain more later if needed.