Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
KDE GUI

newdocms: Beyond the Hierarchical File System 742

Posted by michael from the new-pair-of-dimes dept.
Manuel Arriaga writes "After two years of hard work (and many scrapped versions), I have just released a (ugly, but working!) preview version of newdocms, a completely new document management system. newdocms isn't a file browser: it is a layer between the hierarchical file system (HFS) and the user, which provides a radically new way to store and retrieve documents. No longer will you browse complex directory trees or directly interact with the HFS; instead, you define any number of document attributes when saving a document and then query a database of those attributes when trying to retrieve it later on. For the first time you have a true alternative to the hierarchical file system at the OS level. Through the modification of the KDE shared libraries, newdocms currently works with all KDE apps! (I am looking for volunteers to add support for GNOME and OpenOffice.org!) This is a testament to the power of free software: this sort of innovation could never happen if it weren't for the free software nature of the underlying systems."
This discussion has been archived. No new comments can be posted.

newdocms: Beyond the Hierarchical File System More

newdocms: Beyond the Hierarchical File System

Comments Filter:

  • Pr0n FS (Score:4, Funny)

    by derrickh ( 157646 ) on Friday January 03, 2003 @09:55AM (#5005541) Homepage
    Finally, an OS level method of cataloging my porn by fetish, breast size, and nationality! Thank you Free Software!

    D

  • I already use a different one: (Score:5, Interesting)

    by NineNine ( 235196 ) on Friday January 03, 2003 @09:58AM (#5005553)
    I'm already using The Brain [thebrain.com]. It's *really* unique, and it works. It works very well. And, in addition to organizing files the way YOU want them organized, it also connects random thoughts, web sites, emails, etc. If you haven't seen it, check it out. It's pretty damn incredible.

    • Re:I already use a different one: (Score:4, Insightful)

      by NineNine ( 235196 ) on Friday January 03, 2003 @10:02AM (#5005585)
      This is a testament to the power of free software: this sort of innovation could never happen if it weren't for the free software nature of the underlying systems.

      This is completely untrue. There are lots of other options (like The Brain) that have been out for a while that have nothing to do with "free software". Hell, the fact that other proprietary systems (that are better, in my opinion) came out earlier shows that not only is "free software" irrelevant in this discussion, but it actually lags behind software driven by the profit model.

      • How is The Brain able to dynamically relink all your existing applications to deal with this transparently, when you File->Open inside of them?

        (Assume it uses some crazy undocumented Windows trick) How are we to resolve incompatibilities between The Brain and a software program that has already messed with the Windows file open interface in its own way? Pray, and wait for the two developers to sign mounds of NDAs seems like the only option. And even then, there's no guarantee it's going to get addressed.

        • (Assume it uses some crazy undocumented Windows trick)

          How about instead we assume it uses the well documented Pluggable Asynchronous File System Driver API? So it works with all your existing Win32 applications transparently in a very normal way. Your post is pure FUD.
    • The Brain is an interface on top of your current FS. Things like this have been done going back to the days of the Leading Edge Word Processor (separate file to get around the 8.3 naming conventions).

      I believe the point that this mad scientist was making was that he's completely replaced the FS with this new database-based one.

      It's certainly not innovative, but it's something different I guess.
      • Actually, the article mentions:
        newdocms isn't a file browser: it is a layer between the hierarchical file system (HFS) and the user. It didn't explain it very well on the web page, but I'd assumed that they both did the same thing... give a different interface between the user and the existing file system.

  • Interesting... (Score:5, Insightful)

    by Akardam ( 186995 ) on Friday January 03, 2003 @09:58AM (#5005554)
    It sounds basically like when you want to find a file, you go type in a few pieces of meta-data, and then hit "search". It's a way to do it, but it seems to me (and it's early, so bear with me) that it's easier for me to remember one piece of meta-data (i.e. the path to the file) than several (as it would seem with this setup, as you would have to present more than one piece of data to differentiate between different documents, let's say, created by the same author on the same day). Maybe I'm just used to a HFS, but I find it simple to open up a command prompt and type "pico /documents/foo/bar/fubar.txt".

    Anyway, an interesting concept.
    • It sounds basically like when you want to find a file, you go type in a few pieces of meta-data, and then hit "search".......Maybe I'm just used to a HFS, but I find it simple to open up a command prompt and type "pico /documents/foo/bar/fubar.txt".

      Exactly. Users STILL have to create their own type of organization.
      /documents contains documents. Duh.
      /documents/work contains documents for work.

      The problem is people don't want to be organized, so they look to technology to help them be lazy. Plus try explaining 'metadata' to someone. At least now you can use the file cabinet, drawers, folders, papers example to explain the layout to someone.

      • agree (Score:4, Insightful)

        by ragnar ( 3268 ) on Friday January 03, 2003 @10:46AM (#5005883) Homepage
        I believe metadata is a useful additional means to find files, however I would still want heirarchy as the primary storage. For most people the only metadata they ever consider is the name of a file, and this is often poorly named. I applaud the effort of the person who is doing this project though.

    • Re:Interesting... (Score:5, Interesting)

      by Obiwan Kenobi ( 32807 ) <(evan) (at) (misterorange.com)> on Friday January 03, 2003 @10:11AM (#5005650) Homepage
      Maybe I'm just used to a HFS, but I find it simple to open up a command prompt and type "pico /documents/foo/bar/fubar.txt"


      That's the whole reason for the program -- you shouldn't have to remember long, detailed folder structures and filenames in order to retrieve a file you were looking for.

      I can't tell you how many times I've had to help users find some file, shortcut, document or spreadsheet that they've "lost" because they forgot the correct path. But they do remember it involved a loan, or it involved a party announcement, or something similar. I swear, just the other day I spent an hour waiting on another employee to get off the phone so I could find a folder shortcut another employee had lost. She wasn't sure what folder the shortcut referred to, but she knew it contained documents of a certain type.

      Do you see a pattern here? To me, this sounds just like what Microsoft is trying to do with Longhorn, and potentially Office 11. People are tired of searching and hunting through folders and heirarchies full of oddly named files and temp folders that can confuse Joe User.

      This is awesome software and definitely a step forward. It might not change the geek community, but it will certainly help out system admins of the world. While your method still works (and hopefully, in the future, these two systems should work hand-in-hand, but that's another project I suppose), this is a damn fine alternative.

      • Re:Interesting... (Score:5, Insightful)

        by Elwood P Dowd ( 16933 ) <judgmentalist@gmail.com> on Friday January 03, 2003 @11:00AM (#5006032) Journal
        Except that those users that can't remember where their shortcuts are aren't going to set up good metadata in the first place. So knowing that it's about loans isn't going to help anyway.

        When it comes to that, users just need full text indexing of their documents so they can do full text searches more quickly. Iduno about windows, but we've definitely got that in mac os.

        • Re:Interesting... (Score:5, Insightful)

          by Theatetus ( 521747 ) on Friday January 03, 2003 @11:36AM (#5006384) Journal
          When it comes to that, users just need full text indexing of their documents so they can do full text searches more quickly. Iduno about windows, but we've definitely got that in mac os.

          Great for writers, not so good for graphic artists. I sysadmined for a few years in a graphics/video shop that had tens of thousands of images on the various fileservers. I essentially wrote a very simple version of this "DB on top of FS" idea because I was tired of helping people find their TIFFs.

          Yes, /home/projects/DOJ/annual_report/masters is just one piece of metadata, and some people find that easier to remember than several keywords. OTOH, suppose two years later you want to reuse that image of the hispanic male using a computer. Was that in /home/projects/DOJ/annual_report/masters or /home/projects/USDA/website/images ?

          My solution (and, it would seem, the article's, though I'm sure that one is a lot more robust), was to keep the users away from the FS completely. Just let them bring up all the images tagged with "hispanic male computer." Most graphics shops I've seen either built a DB file manager or bought one.

          Honestly, I think the idea of computers holding a lot of "files" organized into "directories" is a little old. It was great in 1970 but maybe (like this guy is doing) we should rethink it a little. Why not say a computer has certain knowledge ("files") and certain capabilities ("executables")? Rather than naming files, describe the data you want the computer to retain, and retreive it later from that description.

          As somebody pointed out, Office2K/XP and W2K/XP have something like this already, but people don't use it because they still have to name files. That's the crucial step, I think, and that's why I took that power out of my users' hands. They never named files; the app did it for them. Instead, they described files and versions. Abstraction and all that...

          Anyways, this idea may not help everybody, but it sounds like my old users would have liked it (they, btw, were very good about using specific and accurate keywords... no QWERTY effect here; they just didn't think in terms of files and directories). Plus, it's nice to see somebody trying to move past the "files and directories" mindset we've had for the past 3 decades.

    • Not sure it's any better... (Score:5, Interesting)

      by ArthurDent ( 11309 ) <.moc.liamg. .ta. .ytinavsselgninaem.> on Friday January 03, 2003 @10:12AM (#5005655) Homepage Journal
      I agree. Basically the only way this is different from your HFS is that it encapsulates the meta-data (that is currently in the path name) differently. I'm not sure that's any better or worse. In fact, I myself like to be able to see at a glance what all the categories of documents that I have are which is quite easy with HFS, but doesn't sound so easy here. Perhaps that's more because this is a new idea and not mature yet.

      Everyone seems hot to SQL the file system, and while I think that will be the way of the future, I don't think that there is a clear view of how that works from the user's perspective yet. Remember that this is a rather large paradigm shift from what everyone is used to. It's going to take a while for this to mature to the point that Joe User is going to be able to hack it. I mean, I looked at the Save As dialog on that page, and while it looks cool it also looks counter-intuitive to me and I'm a developer! How much more will a user get confused?

      All in all we're going in the right direction, but by no means are we anywhere near the goal yet.

      Ben
    • it seems to me (and it's early, so bear with me) that it's easier for me to remember one piece of meta-data (i.e. the path to the file) than several

      I agree. I'm skeptical of all these UI ideas which start with: "Poor User, he's too stupid to remember filenames, or create a hierarchy that classifies files properly."

      I don't know how many times I've tried to re-find something on the web with Google, but just can't come up with the right search terms to bring it up. That's what happens to me when I think that I won't need the URL, I'll just remember some keywords...

      Plus, the filesystems I have trouble with won't be helped by this. At work, how will a BA tell me where he's stored the requirements on the shared filesystem? I suppose he crafts a query which returns just one single document. But then how's that easier than a filename?

      I just don't get it. In any case, even if it does catch on with joe sixpack, it won't with me.

  • Coming soon from M$? (Score:2, Interesting)

    by Anonymous Coward
    Don't I remember reading something about the Blackcomb file system being database driven? Billg called the current file system a "cesspool" and said it's going to be completely overhauled, IIRC.

    Oh well, in a few years the *n?x-philes will be screaming about M$ stealing their ideas. Figures.
    • The AS/400 and its predecessors have had a database oriented file sysem for centuries (in Moore-law years).

      I find it a nuicance from a programmer's point of view, and indeed it can get quite messy when you have about 100 different Libraries on your 400, each with a few dozen Objects, some of them with another few hundred members etc etc. From the point of view of the application, and the end user (who will typically have only a single version of a few applications installed on his dedicated database server), it is the greatest thing since sliced silicon.

      I think it predates the hierarchical filesystem by a lifetime as well (again in Moore's law years).

  • Remind anyone of something? (Score:5, Interesting)

    by chrisseaton ( 573490 ) on Friday January 03, 2003 @09:58AM (#5005558) Homepage
    What Microsoft suggested something like this [slashdot.org], everyone went mental, and I got bitch slapped [slashdot.org] for saying I thought it was a good idea.

    • LIAR! (Score:5, Funny)

      by gazbo ( 517111 ) on Friday January 03, 2003 @10:04AM (#5005598)
      Microsoft couldn't have come up with this idea: the submission explicitly states that it wouldn't be possible outside the free software model. QED.

  • To Do list? (Score:3, Interesting)

    by march ( 215947 ) on Friday January 03, 2003 @09:59AM (#5005562) Homepage
    This sounds like a traditional to-do list.

    Filing things by categories rather than location.

    Interesting, but you can imply categories by location and thus, to me this is overhead.

  • Sounds familiar... (Score:3, Interesting)

    by mikkado ( 535011 ) on Friday January 03, 2003 @09:59AM (#5005565)
    Microsoft... longhorn... anyone?
    Anyway, it's encouraging to see that an opensource initiative is capable of doing things now, that microsoft plans for a long long far away future :)

    • Re:Sounds familiar... (Score:4, Insightful)

      by mccalli ( 323026 ) on Friday January 03, 2003 @10:18AM (#5005702) Homepage
      Microsoft... longhorn... anyone?

      BeOS, anyone...?

      Cheers,
      Ian

    • Or... (Score:3, Informative)

      by TheConfusedOne ( 442158 )
      ...this is how Microsoft "develops" something?
      [conspiracy_theorist_mode="on"]
      Annou nce it so that you get the propeller heads thinking about it. Someone releases some code and MS uses it for "research".
      [conspiracy_theorist_mode="off"]
      Ser iously, this sounds kind of interesting. The trick is can you limit this to just a document area in the system? Hierarchical FS's work just fine for system files and stuff.
  • Looks interesting, but how is this different from the document management systems that were popular in the 1985-1995 time period? e.g. SoftSolutions, PCDocs, etc? SoftSolutions in particular replaced the Save As dialogue (in Windows 3.1) with a metadata-based dialogue. Is the difference that the older systems used a restricted set of descriptors, and therefore required advanced setup?

    sPh

  • looks like very high quality work, but... (Score:4, Insightful)

    by bartman ( 9863 ) on Friday January 03, 2003 @10:04AM (#5005599) Homepage Journal
    While I do think the work presented is a great idea, it seems to me that it's a lot of effort just to setup the system.

    It would be ideal if the computer -- the thing that is supposed to make life easier -- did the clasification. Until that happens I cannot see myself even considering such a file access method.

    • While I do think the work presented is a great idea, it seems to me that it's a lot of effort just to setup the system.

      Thats pretty much the problem with meta-data based file systems. They're great for new projects, where you have a clean start and can actually add metadata to the files. The real problem is legacy data.

      My home directory weighs in at just under five gigabytes, and has files dating back over ten years, and thats just the "personal stuff". My work partition has about eight gigabytes, which is mainly source code.

      I'm really not going to be able to associate metadata with every individual file by hand. Until automatic tools come along that will data mine the file content and automaticlly do some minimal level of association.

      On top of this a whole new generation of development tools needs to be written. At a very basic level you need a version of make that will build all C source files on the disk with associated meta data "Belonging to Project X, dated no later than last week".

      When you think about it you'll realise that while as a concept its fairly powerful, we won't be switching to using this sort of thing soon. For the same reasons the semantic web [w3.org] and RDF are having problems getting adopted, metadata based file systems face real problems before people will start widly adpoting them...

      Al.

  • Look at the save dialog (Score:3, Insightful)

    by codepunk ( 167897 ) on Friday January 03, 2003 @10:04AM (#5005607)
    My father is really going to understand that. Not a bad idea but the implementation appears to need work. Another interesting thing to note is that this is probably coded in C++ and is going to be a bitch once again to interface with scripting libraries. I love KDE but it is a difficult task to integrate other languages with.
  • ting systems, not that the commercial developers couldn't do it with their own products. Clearly they could. Or are we now claiming that "innvation" belongs solely to the open source community now and not to commercial developers?

  • Didn't BeOS have this years ago (Score:5, Informative)

    by nosse_elendili ( 147250 ) on Friday January 03, 2003 @10:09AM (#5005636)

    "This is a testament to the power of free software: this sort of innovation could never happen if it weren't for the free software nature of the underlying systems."

    ... or not. As I recall, BeOS had a fully functional database driven file systerm although it did not entirely through out the hierarchical side of things either (probably a good decision in my opinion). In fact, I recall reading a while back that future versions of Windows were supposed to have database driven file systems as well.

    While free software is great, let's not get too cocky about what kind of innovations it can produce when we aren't aware of what the traditional software companies have already done.

    • Re:Didn't BeOS have this years ago (Score:3, Insightful)

      by Anonymous Coward
      yes BeOS had it, and I think ReiserFS is planning on similar functionality.

      But this is the first time I've seen it implemented in userland.

      Re: submitter's cockiness about innovation, I think it's simple a pumped up way of saying "if I hadn't have had the source, I couldn't have done this hack". No shit.

      Maybe it's just me, but I think it would have been truly more clever if it had been implemented using a stacked filesystem, or even a hacked open(2).

    • BeOS didn't throw out the HFS entirely but you can define new attributes for the FS. This facilitates searching quite a lot.

      Give BeOS a try sometime.

  • Historical Q (Score:5, Insightful)

    by MacAndrew ( 463832 ) on Friday January 03, 2003 @10:09AM (#5005639) Homepage
    Who came up with the idea of "folders" anyway? Not hierarchical trees, but the metaphor.

    The biggest problem with folders is no one wants to be a file clerk and weed, sort, and file their docs. The act of socking away a doc should as mindless as possible, not because (all) users are mindless but because they have better things to do, and shouldn't spend a minute adding keywords to every doc they might never see again.

    You know how it is -- you're searching and coming up with junk, and want to yell at the computer, do what I meant, not what I said! This would be one of my first pics for AI on a personal computer.

    I agree folders doesn't cut it, though as a metaphor for explaining the tree it's not bad. The problem is the tree.
    • I agree folders doesn't cut it, though as a metaphor for explaining the tree it's not bad. The problem is the tree.

      becaue folders and trees go together like... leaves and filing cabinets! ;-)

    • Re:Historical Q (Score:3, Interesting)

      by ajs ( 35943 )
      I think the tree model is ideal. What is not ideal is everything after the tree.

      The file selection widget (FSW) is a core element of any high-level toolkit, and yet I've never seen one that provided any kind of utility that I need to make a filesystem work well in a GUI.

      For starters, all FSWs should have memory, and they should understand what they're being used for. All of my graphics apps should "remember" where the last graphics app saved a file and default to that directory. Same goes for opening a file. Or office apps.

      They should also have a history pull-down.

      We also need a graphical abstraction for the filesystem (other than the MS-like horizontal tree) that customizes itself through use. If, for example, there are three directories that I load and save files to/from all the time, they should be the most obvious and accessible things in the tree.

      Do these things, and graphical interaction with a filesystem makes sense.

      As for a metadata filesystem, I think there's utility in it to some extent, but unless "rm" understands it, and it's easy to use from that level too, it's useless to anyone who really USES a UNIX(-like) system.

      • Re:Historical Q (Score:3, Informative)

        by Reziac ( 43301 )
        Corel products have been doing essentially that for years -- you can set any number of directories as "places to find whichever sort of file", named and sorted however you like. And they do remember where you were working last time you had that app up.

    • Re:Historical Q (Score:3, Informative)

      by soundofthemoon ( 623369 )
      Folders as a way of describing file hierarchies were part of the "desktop metaphor" that was developed in the late-70s/early-80s at Xerox PARC as part of the Xerox Star system. (I might have some of these details wrong, I worked at Xerox in the 80s.) The whole point of the desktop metaphor was to transform geeky computer internals into concepts the average office worker or exec could understand. Star even used "file cabinets" to organize folders.

      Anyway, we did a lot of other cool stuff at Xerox in the 80s. There were two other information management systems that used non-hierarchical organizations. The Analyst (implemented in Smalltalk-80) and NoteCards (in Lisp) both had lattice file systems. You could create arbitrary links from one item to another, with lots of different kinds of links each with its own semantic meaning. It was an amazingly powerful way to navigate your files.

      Why go to all that trouble? Because we found that it didn't matter how carefully people filed stuff away, they always were losing things. So the important thing was to make it as easy as possible for people to find their files, either by browsing or searching. In The Analyst, a document could be linked to by multiple folders, keywords, or other documents. The browser and search tools took advantage of the richness of linkages to make finding things easy. You just had to remember a few things about the item to locate it, rather than having to recall /a/maze/of/twisty/little/folder/names/all/differen t.

  • This system would demand a lot of discipline... (Score:4, Insightful)

    by MyNameIsFred ( 543994 ) on Friday January 03, 2003 @10:12AM (#5005660)
    ...you define any number of document attributes when saving a document and then query a database of those attributes when trying to retrieve it later on...
    The problem I see with this system is that it requires you to be disciplined when you save a document. I could see something like this working for things like MP3s where there is an internet database that could be used to select the appropriate attributes. However, in the work environment where you're cataloging Word files and Excel spreadsheets, I don't see it as useful. From my experience, when I'm searching for an old file, its never for the reason I would have guessed, so I wouldn't have picked the right attributes when I saved it. In fact, I find it best to use features such as the MacOS X find dialog (or grep on the command line) that allows me to search by content.
    • Furthermore, it's hard enough to get people to give their documents reasonable names. Convincing them to tag their files with accurate meta-data seems like an exercise in futility. I can hear the conversations:

      IT staffer: "That's the 3rd quarter financial report? You should click 'Financial', 'Quarterly', 'Company-wide', and 'Public'."
      Secretary: "I already named it T42f.doc. Get it? 'T' for third. '4' for quarter. '2' for 2002. 'f' for financial - 'F' is for filing'."
      IT staffer: "But noone but you can find it!"
      Secretary, with a wink: "Hmmm... I never thought about that."

      I'm really not joking. If you can't get people to use filenames like "Prelimary quote to Foo, Inc. for widget sales 2002-12-23.doc", why are they going to bother picking those attributes from a menu?

      How about this: Give the users a palette of choices (with the ability to add more as required), and generate the filename based on their choices. Don't even give them the option of whipping up their own personal hash table - make them let the program come up with reasonable names for everything. You could even set a threshold, such as "At least one attribute from each category must be checked", or "every file must have at least 4 attributes".

  • Proprietary file formats are to blame. Imagine if every file format was similar to open office xml based documents. A background process could be indexing the documents and making available very powerful searching. Then add a natural expression engine on top to get the documents. "show me all documents that contain the word resume"

  • Mom and Dad file system (Score:2, Insightful)

    by dmorin ( 25609 )
    Who needs this? As one poster put it, isnt the path the only real piece of meta data you need to find a file? Think about mom and dad. What do they want to know? "Where are the christmas pictures of the baby from last year?" "What happened to that email I sent my brother last week?" "Where's the latest copy of my resume?" and so on. Natural language aside, these are all metadata-type queries (mostly dealing with time and filetype data, both of which can be extracted without any additional effort by the user). I think that if such a system of searching files is ever perfected, we'd have a serious killer app on our hands. Isn't this part of what the "semantic web" is all about? Isn't it frustrating to everybody that even the best search engine in the world still can't understand "find me all books whose author is mark twain"? It seems like a logical progression to expect that. Just like most of us aren't searching the web for *pages*, but rather particular *informatin* on those pages, I think that Joe User doesn't care about looking for *files*, but rather the information contained in those files. Thus it's only reasonable that if you give a user a way of easily describing those files by something more than just a filepath, that it will then be easier to find the information later.
  • or something very much like it a few years ago.
    i used it and it works like a charm.

    of course hierarchical file systems are easy to use, you can name folders after categories, and they are easy to backup.

    Interfacer.

    all your HFS are belong to us.

  • Whooooah!! (Score:3, Funny)

    by Marxist Commentary ( 461279 ) on Friday January 03, 2003 @10:16AM (#5005688) Homepage
    Thought that said new dot coms for a second there! Not again!

    But thankfully, it's an article about file systems.

  • Prior art? (Score:3)

    by Sebbo ( 28048 ) <sebbo AT sebbo DOT org> on Friday January 03, 2003 @10:19AM (#5005707) Homepage Journal
    Sounds a lot like BFS [dhs.org].

    If memory serves me correctly, the BeOS team was originally trying to do a pure database filesystem (no hierarchy), but found (in the early '90s) that the performance hit was too heavy on the hardware of the time.
  • The whole desktop/file/filesystems may indeed be ripe for a new metaphor to help conceptualise them. When computers were the principal domain of workers, the idea of a desktop with files and folders allowed them to grasp alien concepts.

    But computers are becoming ubiquitous, pervasive. Perhaps a new metaphor could be found. An example could be objects in rooms. Think of different folders as different rooms - all files (or rather, all streams) are objects in those rooms. Navigation between rooms is possible through doors.

    Of course, as others have pointed out, the HFS ain't broken, so why fix it? (Answer: why not? PC cases aren't broken, but we still have case-modders, don't we?)

  • Data volume (Score:2, Insightful)

    by jocks ( 56885 )
    It seems to me that the majority of people who reply with "I use HFS just fine, file-> save as -> my documents works just fine" are also the type of people who don't actually create more than a few documents anyway.

    I write a lot of documents and my filing system becomes ever more difficult to manage, without the skills that a librarian or filing secretary has I find that my documents become harder to locate over time. To me this is a potential solution to that problem, I do however appreciate that "Joe Bloggs" will not understand what it is about, but as far as I am concerned "Joe Bloggs" should not be using computers in the first place. Pandering to his ilk has set computing back 10 years.

    The potential pitfall of this system could be where many documents have been written about the same subject i.e. testresult001.txt to testresult999.txt. The user would know with the traditional system that he wants testresult823.txt but with the new system would be presented with 1000 choices. I am possibly being myopic here!

    Perhaps it is time for a new paradigm and I for one will be looking at this method with great interest.
  • Sounds like Microsoft Sharepoint to me. Sorry, but that doesn't excite me too much...

    If so, and based on the bad Sharepoint implementations I have seen, this seems unlikely to be world-shaking. How about a follow-up article on this in a year?

  • Amazing. (Score:3, Interesting)

    by Gyan ( 6853 ) on Friday January 03, 2003 @10:25AM (#5005739)
    This is exactly what I have been wanting for almost a decade now.

    Some uses I imagine

    - Create music playlists on the fly (MoodLogic doesn't count)

    - Categorize work files (Across the whole partition, find images that serves as bumps, HDRI ..etc as well as those that are simply wallpapers and photos). More importantly, if you see a good bump texture for a certain surface, describe it as such without changing the filename.

    - Install Windows and service packs first, mark files as "windows native". Then install apps. Some OS glitch, you need to reinstall ? Backup all files with directory structure which don't have "windows native" tag alongwith c:\program files and registry. Reinstall windows, restore the backed up files. Voila, no app installations required.
    • Addendum : Regarding the third point, only when this happens on windows.
      • Duuuuh.

        Sorry, last clarification.

        You can do this for Windows now as well.

        Simply boot into Linux and tag. Then while reinstalling win, do the above from Linux.

  • Plz don't forget E-Mail and Web documents (Score:4, Insightful)

    by egghat ( 73643 ) on Friday January 03, 2003 @10:31AM (#5005771) Homepage
    I have used "The Brain" while I was in Windows, but it was nearly useless as it didn't support the two most important things:

    a) Web browsing

    it should now the sites you've visited, know your bookmarks and allow you to open everything you have found with a simple click.

    b) E-Mail.

    When it finds an E-Mail a simple double-click should be enough to open it in your mail, show you the thread it belongs to, etc.

    I guess, that I'm not the only one, who has more important things in mails than in .docs or .xls.

    Bye egghat.

  • Reiser4 anyone? (Score:2, Interesting)

    by mrhandstand ( 233183 )
    I was reading about Reiser4 [namesys.com] last weekend and HR mentioned similar functionality [namesys.com] IIRC. I would hope everyone can sees the point behind metadata...it's kinda the reason XML is considered a GOOD THING. The question is...can we shift our paradigms to use this newer model? Change is hard to effect...this would have to be adopted be a mainstream OS for this to really catch on and be widely used. (Asbestos uunderwear on!) Isn't Longhorn's new DB filesystem also supposed to offer some or aLL of this? (RTFA if you want to reply please!) MS might not be as behind the curve as we'd like to think....time will tell if this will actually be widely accepted. My .02.

  • Classic Example (Score:2, Interesting)

    by Curialis ( 218588 )
    of the difference in the GUI vs. command line mind set.

    These abstraction layers have been used before on OSes such as MAC OS and OS/2. The problems always came into play when you pass the files around. There is always a step that strips the extended information. The key is wide acceptance and establish a standard for the data storage. Be sure there is a way to pass the extended data in a text format (i.e. XML) when you want to store the files on a non-supported system (or so command line tools can be easily modified to update the db).

    The idea is good and I am sure it will be very useful to a lot of people. Good Luck.
  • Personally, I do not think computers need to move towards making things yet easier for the user (instead people need to get a clue!). I do see how this might save some in support costs, but the end result will be dumber users, who now still can't find things, just for different reasons.
  • this sort of innovation could never happen if it weren't for the free software nature of the underlying systems

    Surely this is an overstatement. I think what you mean is that a guy off the street couldn't add this file navigation scheme to an existing commercial OS, not that the commercial developers themselves couldn't do it. Or are we now suggesting that the open software movement is the sole owner of the term "innovation"?

  • This should be implemented at the FS level (Score:4, Insightful)

    by Anonymous Coward on Friday January 03, 2003 @10:38AM (#5005825)
    So where do your documents go when you save them with newdocms? As you might have noticed (if you looked at the window titles after saving something), they are stored as ~/Docs/{numeric id}.{ext}.7 All the metadata is stored in a file called ~/newdocms.db. (It is not wise to delete it!) In that file each document's attributes are associated with its unique numeric id (the one which is used as a file name).

    Right.

    This is astoundingly bad software engineering.

    Manuel, when your software fails, and it will, and somehow that db file gets trashed you've rendered that users' files as a huge heap of unsorted data. Effectively it would be 100 times worse than never implementing your system than 10 times better. No matter how bulletproof you think your code is, it probably isn't 100% perfect so having all your eggs in one basket is unwise to say the least.

    Even if your code is 100% perfect this is a mistake. What happens when a sector goes bad and this file is trashed? What happens when the first really dangerous linux worm makes it a point to delete *.db from the filesystem?

    Give the files names that are coded with human readable attribs! Double up that db file! Jesus, man... build SOME kind of redundancy in your system before you throw away the old way of storing the data.

    There's a reason why there is such a scramble to implement a general attribute system at the FS level on many FS projects right now(*). The time has come for OSS to start being smart about this, but cramming all your metadata into a single file and throwing the backup out the window is just a very, very poor idea.

    (*) BeOS was, yet again, way ahead of it's time with BeFS.

  • Doc Management (Score:3, Interesting)

    by MeanMF ( 631837 ) on Friday January 03, 2003 @10:38AM (#5005826) Homepage
    This looks a lot like something I've used in the past - FileNET Content Management Services. FileNET lets you create meta-data for each document you save, as well as a complete version history and check-in/check-out for each document if you want to. It also allows for hierarchical storage of files as well as using the meta-data so you can still categorize things by folder if you want, but still query documents by any of the indexes that you have built. It will even add a full-text search across everything in the library if you want, and it has no problems indexing most standard formats including Word and PDF files.

  • Metadata? And so has it Sharepoint (Score:3, Informative)

    by Koyaanisqatsi ( 581196 ) on Friday January 03, 2003 @10:43AM (#5005851)
    Microsoft Sharepoint [microsoft.com] also allow you to store your own metadata with files - and also grab the "properties" from office files. This is not to substitute the folder tree, but in addition to it, and it's indeed a great tool (aimed more at the corporation than the individual)

    But it's MS and here I am burning karma for just mentioning it. Big deal, I can spare the karma :-P

  • More radical please (Score:3, Interesting)

    by melonman ( 608440 ) on Friday January 03, 2003 @10:45AM (#5005875) Journal

    The system I have been dreaming of for a while would be far more graphical (had a quick look at thebrain.com, it's still text with a few lines as far as I can see).

    My dream system would enable you to specify file attributes such as size, path(s), name, type etc, as well as regex greps on the content, and then plot the filing system in 3D space, through which you could move with a joystick. You would be able to assign attributes to graphical features, eg make scripts cuboid, text files spherical, bigger files bigger on a logarithmic scale and so on. Related files would appear like solar systems, and by changing the importance of the file attributes you could change the way the files grouped.

    Probably not what you'd want to use every day, but I'm sure I'd find a few mislaid files with such a system.

  • What is the deal with people wanting EVERYTHING in a SQL/LDAP style databse! Every intern I have to manage out of college seems to have been brainwashed to think that whatever the app, it's data should be in a relational database.

    I like datbases, but for somethings they should not be used!

    When it comes to the OS, I want to be able to text process data EASILY...with BASH! This road leads to things like binary configuration files and that leads to things like the Microsoft registry which I detest.

    Databasizing everything (including the filesystem) IS NOT THE ANSWER

    • Re:If I can't text process it, then I don't want i (Score:4, Interesting)

      by tweek ( 18111 ) on Friday January 03, 2003 @11:24AM (#5006270) Homepage Journal
      Actually I would LOVE to have everything accessable in a database somehow. I've been wondering about something using the userfs stuff. Not really mounting a mysql database as a usermode filesystem but having information from the system available that way.

      I've found myself many times wishing I could just type "select location,filename from datastore where contents like %resume%"

      SQL comes much more naturally to me than the find command does. I would love an easier way to index the contents of everyfile on my system by an arbitrary number of metadata and then have that accessable via a simple sql statement.

      I remember Scott Hacker did something similar with BeFS and his webserver at somepoint but he's long gone as is BeOS.

      Am I the only one that this makes sense to?

  • The HFS *is* a database (Score:3, Insightful)

    by Alomex ( 148003 ) on Friday January 03, 2003 @11:44AM (#5006445) Homepage
    Here's something that is not stressed enough in school: the HFS is a database, with the fully qualified path name as unique ID and basic operations of update, delete, record lock, and retrieve supported across most operating systems.

    Other query operations are supported such as wildcard characters and, in large OSes other than Unix, a variety of other attribute queries (a la "/usr/bin/find" but accessible from "ls").

    Now the file table itself is a database, which can be readily implemented using a relational database. Microsoft NT an other OSes have had such support for quite a while now.

    I'm glad to see the full relational database FS model starting to hit the mainstream. By this time researchers are looking into XML based File Systems (store metadata in XML-like syntax, support any XML query on the files).

    Which brings us back to an often overlooked fact. Linux has, in general, not been at the leading edge of OS research (with the possible exception of the beowulf architecture). This is alright as for many years the goal of Linux was to reimplement Unix on the intel x386 architecture. However we must keep in mind that the really advanced OS features out there have yet to make it into Linux, things such as new environment metaphors, persistent data support, and intelligent user interactions.

  • Windows groundwork (Score:5, Informative)

    by SteveX ( 5640 ) on Friday January 03, 2003 @11:54AM (#5006507) Homepage
    Windows XP has most of the groundwork for this - Windows has actually had it for a while; for some reason the last piece (the filesystem that lets you take advantage of it all) keeps not showing up.

    You want metadata on files? NTFS streams give you a place to store metadata (much like Mac resource forks but with any number of named streams).

    You want to search on the metadata? The Microsoft Indexing Server will build a database and let you search on it (though it's a very strange system to use - in XP go into Administrative Tools, Computer Management, Services and Applications, Indexing Service, System and click on "Query the Catalog". You can do instant searches for all kinds of stuff, look at the help.

    OLE Structured Storage is like a single file version of the filesystem we're talking about - a way of saving a bunch of objects (some of which you didn't create but that are in your document) into a file. I believe Microsoft's Office apps use it (could be wrong there though).

    Right-click on an MP3 file and pick Properties in XP and go to the Summary tab. There's the metadata - the stuff the index server is going to index. If you add a new file format to the system, you can supply a DLL that will be able to supply the metadata for those files - so you download an MP3, save it on your disk, and the index server uses the DLL to get the metadata and add it to the database. It works pretty well.

    I don't really have a point to all this, just listing some stuff that Windows has that "should" make it easy for Microsoft to add the OO FS someday and have it instantly work with existing apps.

    - Steve

  • Use Case Scenarios (Score:3, Interesting)

    by Enonu ( 129798 ) on Friday January 03, 2003 @12:43PM (#5006900)
    Case 1:
    I'm your average home user, but even so I have about 100 documents I work on. However, I was smart enough to give them meaningful filenames and locations where it takes only a few seconds to find the file. Remembering attributes for each and every file would be a pain.

    Case 2:
    I'm a developer. I'm sorry, but I want file Y in F/O/O/BAR. I need something exact to describe where a file is at least. Anything else doesn't work.

    Case 3:
    I'm a mornon who doesn't give a flying-f*** about where I put my files, and I don't care what I name them. I already have documents in my C\:, C:\Windows/Temp, C:\sdf34\, and C:Documants. It takes me a couple minutes or two to find a file. What? I have to classify by keyword now? Who do you think I am? It needs to classify the files for me or I won't have any of it.

    Case 4:
    I'm a scientist/business man that deals with classifications on a day to day basis. I already have a database because I needed it to be efficient. If it was on the file system level, then it'd be pretty cool.

    I can't think of any other positive cases where this product is useful. Thus, it's my bet that it'll be niche forever. Anybody got any other use cases that I'm obviously missing?

Slashdot Top Deals

To the systems programmer, users and applications serve only to provide a test load.

Close