On Wed, 2012-03-28 at 14:24 +0200, Emanuel Rumpf wrote: > Am 28. März 2012 05:46 schrieb David Robillard <[email protected]>: > > On Wed, 2012-03-28 at 03:27 +0200, Emanuel Rumpf wrote: > >> This allowed the SM to: > >> > >> - tell the user if a certain file is part of any session registered at the > >> SM > > > > Why would the user care? > > > > (Lets assume I haven't use a certain machine for half a year...) > For many reasons: > > - deleting - I would like to know, if I'm allowed to delete a certain file, > thus > it's important to know if it is still used by any session > > - destruction - I'm planning to use a destructive application an a file > and would like to know, if this file is used by any session, where > this modification would cause trouble > > - duplication and release - one may intend to export all files (maybe > of a certain type) for a certain session and send them to a friend. > > - freeing disk space - I would like to remove all files not used (anymore) by > any session (or by a _certain_ session). how else would I know ?
I am not particularly interested in reinventing the file system. I'm interested in a REALISTIC solution to the simple problem of session management. Anyway, these arguments only really make sense in at a hand-wavey level of abstraction. Let's jump back to reality and give these files a name. The user is going to delete, say, their grand piano sample bank, and need a special program to tell them that this means all that stuff they used that sample bank in will break? A user about to do so is actually going to check with this special program before deleting things? Every application is going to check with this special program before opening things that may be used destructively? (What applications even open things at random places on the file system destructively anyway). Users capable of using music production software are perfectly capable of loading files, and understanding that deleting things makes them go away. I've made some disparaging user jokes in my day, but good grief... All of this is ridiculously fragile anyway, and depends on every single file used by anything anywhere actually being imported in to the grand central file store. That is a fantasy, not a feasible reality. Users already have their organized collections of audio, samples, etc. and they aren't going to throw away their organization scheme and import them en-masse into this thing. I will stress again the point that ignoring implementation burden is guaranteed death of any such proposal. Facts: * Every file used by an audio program is not, and will never be, in a centralized location * Many programs have pre-defined state structures where files must be at particular paths. They can not and will not implement anything that breaks this and requires them to use a special interface for loading files * Any simple link-like mechanism is equivalent in power, so any such mechanism that isn't plain file-system links is imposing implementation burden across every layer of thick systems (including existing libraries), for little to no benefit If this makes sense, let's hear something that *can not work* without it. That might offset the MASSIVE implementation burden. Maybe. -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
