On 2007-02-26, Sam Mason <[EMAIL PROTECTED]> wrote:
> Sounds similar to "bitmap indexes" as used by databases. For read-only
> access they are great but AFAIK every implementation I've every heard of
> kills concurrent modification. It may all work out here, but just to
> warn you!
Well, I don't really need concurrent modifications. File creation
or deletion can be considered atomic.
> By pruning I'm guessing you mean getting single references out to each
> file, if so I think I must be missing something. I don't see why any
> algorithm would ever return more than one reference to the same file and
> hence you would ever need to do any pruning.
By pruning I mean producing suitable output for 'ls' or so. I search
on SetFS by a set of tags simply returns a list of files/objects, whose
sets of tags contains all of those tags (plus other possible filtering).
But you don't want to display all of the results: you want to, if you
will, 'cluster' them, so as to produce a hierarchy of results. That's
what I call pruning: displaying a minimal set of tags that can be used
to access all the results.
Suppose the search for 'foo' returns the following files
foo/bar
foo/baz/quk
foo/baz/zum
(Note, there is no file 'foo/baz' in this example!) We don't want 'ls'
to display all of these results, but instead want to prune for the
following output:
$ ls foo
bar
baz
> Your alternative sounds a lot like what I was trying to say in my last
> email.
Maybe, but this is strictly at the implementation level: applications
are unuaware of any ordering of tags.
> Postgres has reasonable support for BLOBs, providing an interface very
> similar to Unix's open/read/write/close.
I hate programs that want to run bloated server software on my computer.
SQLite or Berkeley DB I could deal with, but I don't think a normal DB
is of much help.
--
Tuomo
