Slashdot Mirror
newdocms: Beyond the Hierarchical File System
Manuel Arriaga writes "After two years of hard work (and many scrapped versions), I have just released a (ugly, but working!) preview version of newdocms, a completely new document management system. newdocms isn't a file browser: it is a layer between the hierarchical file system (HFS) and the user, which provides a radically new way to store and retrieve documents. No longer will you browse complex directory trees or directly interact with the HFS; instead, you define any number of document attributes when saving a document and then query a database of those attributes when trying to retrieve it later on.
For the first time you have a true alternative to the hierarchical file system at the OS level. Through the modification of the KDE shared libraries, newdocms currently works with all KDE apps! (I am looking for volunteers to add support for GNOME and OpenOffice.org!) This is a testament to the power of free software: this sort of innovation could never happen if it weren't for the free software nature of the underlying systems."
SQL is not good enough, because it subtract features, add arbitrary restrictions and is not as simple and powerful as the relational model for database management.
What we really need is a really relational, full DBMS (with sane defaults) as the fundamental storage component of an OS.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
How much revenue is made from this?
In a time of disasterous unemployment and financial breakdown in the technology sector of the economy I think the money-making question is _very_ important regarding all new projects.
I think that this program highlights a problem with *nix that really needs to be addressed before it becomes a truly mainstream desktop OS. Namely, the filey system is so complex that it is extremely intimidating for a new user to know where things are located. At the risk of recieving nasty comments in reply, MS has known for years that documents, programs, and OS should be placed in their own distinct directories. This program is a step in the right direction, but the underlying issues that it deals also require attention.
Well, I might as well be unpopular today. I do understand the reasoning behind this product. As a Windows developer (bye, bye, Karma), I frequently have to deal with paths like "C:\Documents and Settings\myUsername\My Documents\Visual Studio Projects\My Solution\Some Project\bin\Debug\datalayer.dll".
However, if I wish to search an area of the namespace, it's simple enough to set up an Index Service catalog for it (bye, bye, more Karma). So long as you're sane about it and don't index your entire filesystem, things perform fine. I use the search feature all the time. Sometimes I even define keywords on the file for searching.
If I don't use the indexer, I can always use grep, file search, or whatever, to search the namespace by content. It takes a few extra seconds, but it works.
Email is a great example of this. If you're anything like me, you get 10 spams for every real email you get, and I get lots. A few years ago, I got tired of constantly filing all my email in a folder structure. Now I just treat my inbox like a giant stream and search it whenever I need anything. The mail is already stored in a database (Exchange 2000, bye bye Karma!), and the search is quick even with a few hundred megs of mail being searched across my VPN. If I ever get around to installing SpamAssassin, my methods may change.
Now, I'm sure I'll get slammed for using Microsoft products, but the fact is I've got gigs of data on my primary development box. I've got every remotely important file and email I've ever worked with in the last ten years - pared down to about 20GB of data. I'm sure I'd be completely lost without these search features.
How is this new product different?
BRENT ROCKWOOD, EST'd 1975
Shouldn't this be posted on FM?