Re: [LAD] NSM - handling large files

From: David Robillard <d@email-addr-hidden>
Date: Fri Mar 30 2012 - 02:40:58 EEST

On Thu, 2012-03-29 at 22:23 +0100, Rui Nuno Capela wrote:
> now back to square one. to make that whole session state, folder or
> directory, as an archival portable one is, quite frankly and imho again,
> utopian. nuff said :)

It's indeed utopian to think that some centralized special magic program
and protocol and file format and whatever else will actually get
universally adopted.

However, files and directories and links are anything but
unrealistically utopian. That's my point.

With all due respect, Emanuel, you can see here what happens when you
make a big complicated mess out of things and try to ram technology down
implementer's throats without justification: they simply reject it
outright as a utopian fantasy.

Achieving archival/etc is *trivial* without any fancy/annoying session
management crap whatsoever. If apps want to save in a way that prevents
it, they will always be able to, however if they do, there is *one*
simple rule that makes *all* the mentioned functionality possible that
has nothing to do with any specific session manager API/protocol/file
formats/etc whatsoever:

 * All references to files outside the session directory must be a
symlink to that file

That's it. No APIS, no protocols, no session manager file stores, no
redundant data that may not match reality, no egregious rules. There's
not even a requirement for a session manager to be involved whatsoever,
if an app saves this way independently you can archive its sessions with
tar or whatever just the same. If you did want a fancy GUI archival
tool that reports what files are used and whatever else, you could write
one, and it wouldn't even depend on the session manager at all - and I
don't mean it would loosely depend on it by only using OSC or whatever,
I mean it would not depend on it *at all*, nor would it depend on any
file format[1]. All even vaguely common languages have everything
required in their standard library, right now. All of that Just
Works-eyness is because it's a simple idea, and doesn't use anything
that hasn't been baked in to the OS for literally decades. It doesn't
get much less unrealistically utopian than this.

Erecting some fantastic non-existent architecture to achieve, in one
special circumstance, what this simple rule does, is a folly doomed for
failure. To really distill it down, since we're on a "reality" trip:
you can either try to get people to adopt this convention, or you can
not have archivable/distributable sessions. There is no option C.

That said, if I'm overlooking something, do tell (i.e. why, exactly, is
this simple plan not sufficient?), because from where I'm standing it's
a real mystery why we are acting like this is so damned complicated.

It's not. At all.

-dr

[1] Try to sell any file format to this crowd and see how far you get...

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Mar 30 04:15:01 2012

This archive was generated by hypermail 2.1.8 : Fri Mar 30 2012 - 04:15:01 EEST