Journal cyclomedia's Journal: a true database driven file system
all files given unique id (local to system). could be based on time file was first created in milliseconds or a counter that starts from a random offset (so that os files arent in predictable locations)
database layout:
file_id = unique id, used by all filesystem operations, shortcuts and link tables
name = name
description = long description
type = type: e.g. "audio/mp3" (this replaces the file extension)
meta = descriptor: audio
flags = read/write/drm etc
binary = the file's binary data
->depends = link table of files that this file needs
->dependant = link table of files that need this file
etc.
files in this system no longer have a physical location, they can be mapped to by any means. different users could "see" the filesystem any way they wish:
the windows "my documents" folder would not be a folder but a query or link table, the technicalities of this hidden from the casual user.
mp3 files could be listed by artist, genre, decade etc. and playlists could simply be link tables. all of these could be represented in the GUI much like standard folders are now: a user creates a "folder" and drag-drops files into it to create "shortcuts" to the original. the database spec itself would be internally extensible, mp3 files can have artist,title,albumn,mix,length,bpm,etc set but a track appearing on an albumn and a compilation would need duplicate entries, forcing a fully relational setup. indeed mp3 files would no longer have one name to refer by no more "jimi_hendrix_experience_are_you_experienced_track_01.mp3"!
a linux config file could be simultaneously found in //etc/config and //programs/myprogram/config for example, different runlevel configs could also be seperated this way. uninstalling a program would involve removing all it's dependancies (tracked via a link table); if a dll file has no dependant links, then it is safe for deletion. if a program attempts to install a dll file that is identical to one on the system a copy is not made, only the links are updated, the program installer need not know if this has happened.
seamless network integration, if my brother's pc has a bunch of mp3 files on it and we're on the same network our mp3 lists and queries would appear as one, good gui design would show the distinction between local and external files (e.g. different color) and options to create a local copy would appear under the context/right-click menu. with (buildable) options for getting all-by-artist all-by-album all-in-this-or-that-playlist etc. files that are identical but exist on both could be shown normally or have another color, user definable!
once we get away from the rigidist tree-and-leaf thinking of filesystem and network layout then there's a lot that we can do (and not just sort our mp3s and holiday photos)
database layout:
file_id = unique id, used by all filesystem operations, shortcuts and link tables
name = name
description = long description
type = type: e.g. "audio/mp3" (this replaces the file extension)
meta = descriptor: audio
flags = read/write/drm etc
binary = the file's binary data
->depends = link table of files that this file needs
->dependant = link table of files that need this file
etc.
files in this system no longer have a physical location, they can be mapped to by any means. different users could "see" the filesystem any way they wish:
the windows "my documents" folder would not be a folder but a query or link table, the technicalities of this hidden from the casual user.
mp3 files could be listed by artist, genre, decade etc. and playlists could simply be link tables. all of these could be represented in the GUI much like standard folders are now: a user creates a "folder" and drag-drops files into it to create "shortcuts" to the original. the database spec itself would be internally extensible, mp3 files can have artist,title,albumn,mix,length,bpm,etc set but a track appearing on an albumn and a compilation would need duplicate entries, forcing a fully relational setup. indeed mp3 files would no longer have one name to refer by no more "jimi_hendrix_experience_are_you_experienced_track_01.mp3"!
a linux config file could be simultaneously found in
seamless network integration, if my brother's pc has a bunch of mp3 files on it and we're on the same network our mp3 lists and queries would appear as one, good gui design would show the distinction between local and external files (e.g. different color) and options to create a local copy would appear under the context/right-click menu. with (buildable) options for getting all-by-artist all-by-album all-in-this-or-that-playlist etc. files that are identical but exist on both could be shown normally or have another color, user definable!
once we get away from the rigidist tree-and-leaf thinking of filesystem and network layout then there's a lot that we can do (and not just sort our mp3s and holiday photos)
