It allows all programs to potentially operate on data managed by this engine. Its structure is similar to Windows Registry with a difference, that it also supports BLOBs and its size is not limited. It could be used instead of filesystem directly. The equivalents of registry keys are named sections.
There are two the most common methods of storing data by applications. The first one is based on the file system. On the other hand the database engine can be used, mainly based on SQL. There are many SQL servers, but to tell they do not much differ between one another regarding the philosophy of data access. Not in all situations using of them is recommended.
So the idea of tree oriented data could fill the basin between file systems and SQL databases on the other hand. It would be useful in for example CAD applications.
Let us consider a CAD application used in electrical devices and installations design. When the design GUI appears, the user can insert logicals symbols, and connect them by lines. The palette of symbols is located besides the design area. The symbols are stored in a library.
To cut a long story short the applications used 2 kinds of storage, one for projects, the second one for symbol library. Both databases can be used by multiple users. How to manage data related to symbols? What database should be used for this?
In this case a hierarchical database engine could be very useful. The used section tree is shown on a drawing below. Symbols ar stored in BLOBs. When any symbol is copied from library to project, it can be linked. A separate copy is redundant in this case.
The source code together with documentation is located at Google Code Site. Please, read it if someone would like to read something more about it or join the project.
If you want to join the project, please contact