<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hmm, yes I suppose this would be a real problem.  One way round this would<br>be to have dibdirectories like 001, 002, 003 ... with 50 or 100 files in
<br>each.  It's ugly, but if we have to compensate for the shortcomings of<br>some filesystems, it'd probably going to have to happen sooner or later.</blockquote><div><br>
I agree that current attempt to map keywords to a category hierarchy is
too messy; they're different concepts (sets and trees).  But as long as
you need some kind of directories for performance reasons, we could
still make them somewhat meaningful; say, authors, or maybe the first
letter of the title? </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Another possibility is to abandon using the filesystem for distinguishing
<br>keywords, and have some sort of index with an application for finding the<br>files...  This would make us bit more of software project (one that might<br>not be easy to do in a truly cross platform way), but it would certainly
<br>enable us to avoid the file duplication problem.  Mind you, doing it well<br>would be tough.</blockquote><div><br>
This is conceptually the best solution, I think.  Again, without
wanting to go off on a rant, the concept of "subjects" or "topics" is
better represented via sets than trees.  This is how OCAL (ands
lots of currently hip web services) seems to be trying to organize its
content but we're running up against the tree metaphor of the
filesystem.  This is largely how I implemented local clip art
access in the clip art browser.  If people can tell me
specifically what they want, I'm happy to build something like this.<br>
<br>
Greg<br>
</div></div><br>