Filesystem

I'm thinking we could use something similar to libgmailfs seeing how it already has some form of meta-tagging. The APIs for current implementations seem very well documented so hopefully we could just tweak it to add whichever tags we deem necessary as well as adding support for various filesystems.

I ran into an interesting project over at sourceforge called dbfs. So far it's basically a proof of concept and has like tons of useless(?) dependencies, like qt and so on. One dep that looks pretty necessary is the sqllite one. (ddew)

I've visited the dbfs website and the Apache jakarta lucene websites (as we talked during the chat session about this topic)

dbfs
Over 30 years people worked with hierarchical file systems; file systems based on directories and files. These file systems have proven their use, but today, with gigabytes of storage and millions of files, managing files with directories is becoming increasingly di cult. This research presents an alternative to hierarchy based file systems. At the basis of this system is a unified approach to all properties of a file. Combining this approach with a drag and drop user interface creates an alternative that is as usable as directories, while in the mean time going well beyond the expressive powers found in hierarchy based file systems. [...]

jakarta lucene
Jakarta Lucene is a high-performance, full-featured text search engine library written entirely in Java. It is a technology suitable for nearly any application that requires full-text search, especially cross-platform. (So it doesnt really fits our needs.)

my conclusions
After exploring this i think that dbfs really fits our needs for a efficient files search & managing tool .
dbfs has a client/server architecture.
The heart of the client and the server are writed in O'Caml.
The server is a daemon that tracks preconfigured paths for changes and update a sqllite db with the infos.
The client (GUI) is designed for KDE.
A C API is given to interact with the server (here is the API reference (PDF))
one of the key features of dbfs is that it doesn't need to change the host filesystem type and 'virtually' works on any existing filesystem.


It should not be too hard to write java bindings for this using jni. there are good tutorials for jni.
Another thing is to understand how the C Api does works but I'm working on this...


I've allready understood this :
for dbfs a file consists in a name, a type, a date, a size and keyword(s).
the keyword(s) are tags added via dbfs (and only kept in db).
other attributes are taken from the filesystem.
(in the next version of dbfs there should be support to import keywords from existing tags (image bitdepth, mp3 bitrate, ID3 tag).


to find something : you take a view and apply a filter to it ant that gives another view :
VIEW x FILTER --> VIEW
A view is 'just' a group of files ...
and a filter is a restriction on one of the file attributes or keywords ...
and u can apply multiples filters like this :
VIEW1 x FILTER1 --> VIEW2
VIEW2 x FILTER2 --> VIEW3
display VIEW3

I doesn't know more but I'm working on it !

(dwarfy 25/01/2005 23.35 )

Problems so far includes the inability to build on most systems, it relies on some arcane features in sqllite (sadly those aren't available anymore). I've been doing some serious battle with it to get it to compile and hopefully I'll have it running soon. Once the daemon is running it should be a trivial task to get a java-client done. The API is in c-sharp but seeing how it uses standard sockets for connectivity I can't imagine why a java-client shouldn't be doable.

(ddew 31/01/2005 13.11)

(nicklothian 3/3/2005)