-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Jun 11, 2007 at 03:10:24PM -0300, Gerhard Fiedler wrote: > The nice thing is to see the list filtering down while typing. At every > letter I type, I see how many entries are there to browse, if I decide I'm > done with filtering. This is a typical GUI function that doesn't lend > itself well to command lining. Actually similar kinds of functionality has been implemented for command line apps before. For instance in bash, hitting tab shows you the list of command, filenames, options whatever that would best match what you are typing. As an example: pete@inept:~$ ls /var/spool/ anacron/ cron/ cups/ exim4/ mail/ masqmail/ openoffice/ pete@inept:~$ ls /var/spool/ Completion works for more than files too, with the bash completion plugins, and there are hundreds written, it'll do things like auto-complete branch names in monotone: pete@inept:~$ mtn --db=io.pkt.mtn co -b io.pkt.soft. io.pkt.soft.mtn-append-robot io.pkt.soft.replate io.pkt.soft.tt io.pkt.soft.tt.devel io.pkt.soft.pk2.debian io.pkt.soft.timetracker io.pkt.soft.tt.conf io.pkt.soft.tt.expense pete@inept:~$ mtn --db=io.pkt.mtn co -b io.pkt.soft. Or even recognise that a given command is only looking for specific types of files, if you are in a directory with ten files, one of which is a pdf, the following works: pete@inept:~/j$ ls new_installer.jar P2165.pdf svn_trans.tailor pete@inept:~/j$ xpdf P2165.pdf Finally the feature isn't actually specific to the command line, it's handled by the readline library which many more programs use, even some GUI apps. > > Indeed, such a system could be usefull for multiple individuals, so > > running a centrally accessible server would be usefull. > > But only with a locally synced copy. Otherwise it loses the snappiness. Of course, I mean, it's a big part of the reason why distributed revision control is so popular. > > It wouldn't be a big deal to make a universal indexing backend that tied > > into the regular file system. MIME types exist to make it easy to filter > > when you want to only search for application/email or > > application/bookmark (made up examples) Everything could tie into a > > UUID, path, or hash as appropriate. > > While it really doesn't seem to be that big of a deal to put a database on > top of the file system that can do this, the problem is probably to create > all the infrastructure for all the programs that access the file system. > Currently they are all path based. But the key thing is to provide a migration path. So long as your new fangled keywords thing works fine with path-based programs the switch over can be gradual. Also most GUI's use common libraries for file choosers, so you can replace the file chooser with a keyword aware one without any changes to the apps. I remember Windows using that during that technique long filenames switch. Unix, with it's piles of GUI toolkits, would be more of a challenge, but the same principle applies. You'd probably one to map some types of URL's onto the path filesystem for backwards compatibility, so for instance: /url/uuid/e0216526-18ef-11dc-b967-00d059b80ee5 /url/sha1hash/052f5890212ef70f57badaebb448c375603b292f would go to something usefull. On UNIX the latter is interesting, the second you change the file, it's effectively deleted and suddenly appears at a new pathname, which is perfectly fine in UNIX filesystems as a inode, the data a filename points too, isn't deleted until all processes accessing it close it. Programs tend to handle that case gracefully. Finally implementing the path filesystem would be quite doable on Linux with the user space filesystem mechanism for experimentation. > > The key thing is to make sure the base filesystem layer doesn't really > > have to know all that much, and keep the things name spaced in usefull > > ways, mime types may be a good model to start with. > > The moment you have your apps integrated and make them use the new > "addressing" mode, the underlying file system practically degenerates and > becomes obsolete. Obselete yes, but having the two side by side shouldn't be a big deal. For instance to get things working you could do some cheeky path tricks: ls /keywords/red_apple_jpegs DCN10134.jpg-uuid DCN13423.jpg-uuid DCN9876.jpg-uuid Where uuid is each files unique UUID, and the first bit is each file's name. That way two files can have the same name, yet still have a unique identifier. Sure stuff like that is a hack, but it'll work, and gives all programs access to the new system as things slowly switch over. - -- http://petertodd.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGbq8H3bMhDbI9xWQRAmTzAKCus0iWKEYUiHdVMg/oeOYb85MEVwCfXRI0 x9ApM2C7ZyNxVQoS56wy4qc= =s2GQ -----END PGP SIGNATURE----- -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist