Re: Hierarchical tag structure in SetFS

On Thu, Mar 01, 2007 at 06:23:03PM +0000, Tuomo Valkonen wrote:
> On 2007-03-01, Sam Mason <[email protected]> wrote:
> > Comments?
> 
> I didn't bother to read all the technical explanation in detail,

I thought it would be nice to have something concrete to discuss, but it
was probably a bit early!

> but it seems to me that you're not after what I'm after. You're
> after a more complex system, where all tags are merely informational,
> meta-data, whereas in my system the tags are the identity.

I guess I have ended up somewhere quite different from where we started,
yes.  I moved away from your idea of a flat namespace for tags mainly
because I don't think it'll scale well.  I did a "find -type f" in
my home directory and went through giving tags to all the files and
surprisingly quickly started hitting places where files would get the
same set of tags or I would have to give files unnecessary tags to make
naming work.  The tags also started to get increasingly byzantine names
as I worked my way down the hierarchy and I can't see any way for this
not to happen.

I think those are the main reasons that I adopted a hierarchy for the
tags.  Once I'd got them I pulled all the features back I could from our
previous discussions and ended up at the idea I sent.

The main point of departure from your system, as far as I can tell, is
that I only use a single binding (tag,name) is used to identify a file
where as you only want the set of tags to identify a file.  You try much
harder to make the existing Unix interface with the system, but I don't
think this difference is as important.

The main reason I use a single tag, rather than a file's complete set of
tags, is because a file's tags will change over time (I think) yet in
the face of this change we want file names to remain working.

> (How else do you provide persistent search results? That's a key
> component in my system: persistency of locations. Adding new files
> does not stop a known path from working for opening a particular file.)

I view search results as just that, the result of a search.  Searching
again at a later date *will* return different results and I don't think
it's sensible to try too hard to make it too stable.  If a file can be
located through just one tag I think naming will be much more tolerant
to change.

> Or otherwise you're just unnecessarily distinguishing that file name.
> In doesn't seem like what I'm after at all.

The file name does become special for me, but I couldn't see any other
way to keep the other properties.


I don't know if I've moved too far away from your idea for the
differences to be reconciled, I hope I haven't and we can bring things
back together again.


  Sam