This page describes ideas for the future development of Knotview. Things will probably change before implementation ! Other ideas are welcome, feel free to send an email ...
Knotview is already usable for daily work, but a lot of features are planned. The main goal is to turn knotdb into a something that is a new "filesystem" paradigm, knotview being considered as a "file manager". Talking with knotdb words, we can speak of knotsystem and "knot manager".
A category can be considered as the equivalent of a directory. In the present state, there is no way to organise the categories (a category cannot be "included" into another one). This must be done for the concept of category to be really useful. Two constraints can be introduced
With only these two constraints, a rather complex structure can be obtained, that cannot be represented by a tree. Avoiding circular inclusion ((A is in B) and (B is in A) means A=B), the structure is something like a no oriented-loops graph. No current widget can automaticaly display this kind of relation in a clear way (contrary to a tree). Any ideas appreciated.
An edge as no equivalent in a classical filesystem. It gives the power to link pieces of information together, exactly as with html pages. For certain cases, enforcing a particular structure is meaningful. e.g. there is no need for a general graph structure for a "to-do" list. This structure can be enforced for a specific edge category. e.g. if every edges connecting "to-do" knots belongs to the category "todo", it can be specified somewhere in the category definition that edges in the category cannot form loops or even branches. The knotdb process will forbid such connections. This leads to several "properties" that are attached to categories:
For example, enforcing a tree-like (read forest-like) structure for a specific category will be described by saying that a knot cannot have more than one parent, and that no loops can exist.
When each cannot have more than one parent and one child and there is not loops, this is a list structure.
A strong constraint with the current implementation is its lack of support for an external text editor. It can be achieved in a very crude way by using temporary files, but this is not a satisfying solution (not robust enough). Connecting an editor as emacs to knotdb is possible, by writing a proper lisp/python interface to knotdb. This will not be possible for something like nano !
Changing the filesystem paradigm on modern operating systems is a lost war. Thousands of softwares uses the posix paradigm and cannot be written to acommodate the knotdb conception. Nevertheless, we can use Fuse to link the two world. Knots could be accessed through a daemon (kdbd, to appear in version 0.2.0). This daemon could handle a fuse filesystem at the same time, allowing "classical" programs to access (at least) texts using a posix interface. This way, each user could edit the texts with his/her favorite text editor.
This raises the question of storing binary data into a knotview database. Knots can be a very useful concept to organise pictures or music files. Playlists can be implemented on the "knotsystem" level, by using edges. It can help avoid duplicates, and avoid deleting files referenced in several playlists.
Added 06 february 2008 : The current kdb file implementation relies on the shelve module, that cannot properly accomodate binary data. (This was nevertheless considered as a quick hack right from the beginning). Future versions of the kdb file will probably rely on the sqlite file format, which can handle more data.