Re: Feature freeze imminent

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