Re: Feature freeze imminent

On Mon, Feb 26, 2007 at 05:29:52PM +0000, Tuomo Valkonen wrote:
> 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.

File lookups would have to stop while tags were being modified though.
But yes, it's much less of an issue for file systems than for databases.

> > 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.

Yes that makes sense now, thanks!

> 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

Why not [bar,baz,quk,zum]? all of these tags appear in files once you've
filtered out the ones that don't have foo in.  But yes, I see why
pruning could be problematic.  I'll have to think about it more!

> > 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.

Yes.

> > 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.

If you're still exploring the problem they can be very good at providing
a flexible data store.  When you more beyond the prototyping phase then
I'd think about something a bit more specific.


  Sam