Re: [LAD] Non Session Management

On Wed, 2012-03-28 at 14:24 +0200, Emanuel Rumpf wrote:
> Am 28. März 2012 05:46 schrieb David Robillard <d@drobilla.net>:
> > 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
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Mar 28 20:15:02 2012