Re: Hierarchical tag structure in SetFS
On Thu, Mar 01, 2007 at 06:23:03PM +, 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
Re: Hierarchical tag structure in SetFS
(Since the other message seems to have stuck in some queye, I'll just reply again here, although I should be replying to myself.) tuomov wrote: But having to use some arcane (numeric) identifiers for persistent access to files instead of their paths drifts too much away from unixland into WIMPland. The following quote explains the connection to WIMPs (Weakly Interacting Massive Programs): The see-and-point principle states that users interact with the computer by pointing at the objects they can see on the screen. It's as if we have thrown away a million years of evolution, lost our facility with expressive language, and been reduced to pointing at objects in the immediate environment. Mouse buttons and modifier keys give us a vocabulary equivalent to a few different grunts. We have lost all the power of language, and can no longer talk about objects that are not immediately visible [D. Gentner and J. Nielsen: The Anti-Mac Interface, http://www.acm.org/pubs/cacm/AUG96/antimac.htm] In a metadata DB FS, files don't have names that we can talk about. We can only search for them in various ways, and point at the found objects. -- Tuomo
Re: Hierarchical tag structure in SetFS
On 2007-03-02, Sam Mason [EMAIL PROTECTED] wrote: 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. I think you're much closer to the usual metadata-based DB file systems than my approach, especially as you don't care about persistent search results, which is fundamental to my idea: if I didn't care about them, any metadata-based DB FS might do it. But having to use some arcane (numeric) identifiers for persistent access to files instead of their paths drifts too much away from unixland into WIMPland. Now, there could be advantages to working with abstract objects intead of paths, and maybe nice command line interfaces could be designed for that, but it's not going to happen in such a time scale that setfs can be implemented in. It would take decades. So I want something that works with existing tools: setfs. I think you're also still confusing the notion of a tag on setfs, and meta-data tag: you're thinking too much in terms of providing lots of description (metadata) for a file, and too little in terms of simply removing the order from unix path names, and providing a non-hierarchical identity. Yes, deciding on an identity for a file can demand a bit of effort, and it is not always clear, but it should be easier to decide on an non-hierarchical identity than a hierarchical one in at least some use cases. I think organisation of random notes could be one of those, and that's why I want to try this in riot. -- Tuomo
Re: Hierarchical tag structure in SetFS
On Fri, Mar 02, 2007 at 01:06:44PM +, Tuomo Valkonen wrote: Come to think of it, perhaps people are going the wrong way about database file systems: implementing them on top of a conventional FS, giving useless names to the files under the database file system's control. Perhaps it would be better to have at the bottom an unorganised data store with only abstract identies for objects, and then have additional systems on top of that providing names to things that need them: traditional hierarchical, setfs-style, whatever fits the application. Files could have names in multiple systems, and Not every file would need to have an identity in any of these systems (except one providing access to the files with the meaningless identifiers in an uniform manner). And how do you ensure that every program can interact with every file? Capability Systems provide a very good way through a pattern that has started to be known as the powerbox, plash[1] is an implementation for GNU/Linux that looks as though it can replace the GTK file-open dialog with one that would return a capability to the file rather than its name. It would be possible to extend this idea and make the plash file chooser aware of different ways of finding files. Sam [1] http://plash.beasts.org/
Re: Hierarchical tag structure in SetFS
On Fri, Mar 02, 2007 at 01:51:51PM +, Tuomo Valkonen wrote: On 2007-03-02, Sam Mason [EMAIL PROTECTED] wrote: And how do you ensure that every program can interact with every file? Mounting the naming system somewhere in the global namespace? Or maybe URL-style stuff, if we didn't have to stick to the unix namespace (which we would): setfs://foo/bar/ URLs are only useful for opening a file when you know the name. I wouldn't like to type complete filenames (with all path elements) each time I wanted to open a file. Things like tab completion and working directory only really work when you have something with similar semantics to a hierarchical file system and can afford to expose the interface. Capability Systems Of course, supposing all files are not in a global namespace, a private namespace is a capability system: to give a program an access to a file, the program giving the capability would map it in the requesting program's namespace and naming system (at a requested location). If you have to work with namespaces then this is about all you can do. Inside a real capability system you would just ask something (the GUI normally) to interact with the user and give you back a capability (similar semantics to a reference in programming terms) to the file(s) the user selected. But I'm not to keen on namespaces private to processes... Capability systems generally don't imply private namespaces, it's just the only obvious way to implement this sort of thing under Linux. Sam
Re: Hierarchical tag structure in SetFS
On 2007-03-02, Sam Mason [EMAIL PROTECTED] wrote: Things like tab completion and working directory only really work when you have something with similar semantics to a hierarchical file system and can afford to expose the interface. The concept of a directory does not really apply, but SetFS can (obviously) have a working set, tab-completion, and so on. Capability systems generally don't imply private namespaces, it's just the only obvious way to implement this sort of thing under Linux. No, capability systems as you put it, only imply hanging onto what you see. But you need to give things some identifiers for the user to be able to talk about them to the system. You need namespaces. A capability system without names is useless. Draggingdropping random icons presenting the objects between programs to give them access to things is totally impractical, totally unusable. You need names that you can just input, without laborously looking up the object -- as is the WIMP approach. Whether every program has direct access to global namespaces, or whether they need to query some other program that only sees the namespace (going to be a _lot_ of work to support various kinds of UIs!), for both the object and the name to talk about, is irrelevant to that. -- Tuomo
