Re: [LAD] Non Session Management

On Tue, 2012-03-27 at 14:24 +0200, Emanuel Rumpf wrote:
> Am 27. März 2012 03:23 schrieb David Robillard <d@drobilla.net>:
> >
> >
> > ... What you end up with is a few directories
> > with specific roles.
> > ...
> > ...
> > Figuring this all out was a long process of trial and error, but now
> > that I write it down it seems clear it can't be simplified without
> > failing to meet a requirement. I am all ears for arguments to the
> > contrary, though.
> >
>
> Thanks for pointing out, David.
>
> 1.
> I don't totally agree with using symlinks:
> - I tend to think, that file-systems are not as efficient as databases

I am having a hard time imagining anything *less* likely to be adopted
than trying to cram a *database* down everyone's throats to save some
files! ;)

I think I'll just avoid going into the why and say: not in a million
years.

> - What if any of the symlink to symlink is deleted - do applications
> still know, where the file is which they had been pointing too ?

What if a file is deleted? What if the entire file system is wiped?
Users can remove files, film at eleven. Nothing to do with symlinks.

> - Some apps would want to store additional info relating to the file
> (meta-data, tags, related info, ...), thus requiring a simple database
> anyway.

So? Apps can store whatever they way. If you are crazy and want to
store a binary database in there instead of a sane file format, feel
free.

No session manager that forces everyone to use some database would ever
fly. This is obvious.

> - having symlinks leaves the user with the question how to reliably
> copy a directory, without messing up everything (dereference yes/no,
> follow links yes/no ...), something that is critical to deside

That is inherent to any solution with "links" to external resources.
Links to external resources are a requirement. If you want to move a
session, use a smart tool that can fix the links, or archive it.

> 2.
> I don't totally agree with a file- vs. copy-directory:
> I mean: is there really a semantic difference between a created, a
> modified file and a copy ??

The argument for these having to be separate is because otherwise the
copies would pollute the namespace. Also remember files can be created
before save time.

> For an app, there may be a semantic difference for
>
> A: existing files a user added, which are ORIGINALS (thus refs),
> never-modified ones
>
> B: files the app created or modified, thus copied - files that are
> NEWONES (thus real and refs)
> note: a modified or created file can become an ORIGINAL for a
> different application !

A file outside the session is a file outside the session. Happening to
be in a directory that happens to be a different session makes no
difference.

> that's what I meant above, in 2.
>
> C: files that are HISTORY, the user may want to delete these anytime,
> to store space
> - a history-file can become an "original" - what now ?

You keep bringing up this "what if the user deletes a file that is used"
problem as if there could possibly be a solution. Obviously there can
not be. Yep, users can delete files. That is not a criticism of any
particular solution.

In reality this is not a problem. Users have a pretty good idea that if
they go screwing around with e.g. their ardour session and start
deleting files, something is probably going to break. Don't Do That.

> 1. large files should never go to the session directory

Why? What exactly is "large"? Just because a file is large doesn't
mean I don't want it in a session. It is a requirement to be able to
roll up a self-contained archive of a session *if* you want to.

> 2. Lfiles shared between apps have to be managed by a (super-)
> instance that knows what's going on - the session-manager - otherwise
> it's completely undefined/unclear what happens

Why? It's perfectly clear. A file is a file.

> 3. Lfiles newly created (recorded / modified ) - for ALL sessions - go
> to a common NSM-Lfiles directory

Doesn't really matter. You can use one. You can use many. Whatever.

>
> 4. The session manager knows, of EVERY reference to files inside the
> NSM-Lfiles dir.,
> distinguishing between
> - CURRENT_REFS (files currently used by any instance)
> - HISTORY_REFS (file not currently used by any instance) (this is
> equal ALL_FILES minus CURRENT_REFS)
> - EXTERNAL_REFS (files referenced by any instance, but not contained
> in the NSM-Lfiles dir. and NOT created/recorded/modified by any
> instance )
>
> 5. this means, the user is disallowed to manually reference/link to
> any of the files contained in the NSM-Lfiles dir (because the SM
> wouldn't know about it)

And why does the Grand Centralized Session Manager File Authority need
to do this? What exactly is the problem that all these rules and
authority solve?

> 6. The SM knows all files-in-use and is able to move unused
> history-files to a dustbin (no app is allowed to use/reference files
> within the dustbin). The dustbin can manually be deleted by the user
> anytime.

The only thing you need to be able to clean up is the location of the
latest snapshot, or the snapshots you want to keep. The rest is a
classic garbage collection. You do not need a blessed centralized file
location for this. It doesn't even make it any easier.

> IF I did not forget / oversee anything critical, this looks like a well managed
> and reliable approach to me. Any opinions ?

To be honest I don't think this dissection of the problem really makes
much sense. Basically in a quest to have a database for a database's
sake you've merged all the directories, requiring a database or at least
index file to keep track of all the special different "kinds" of files
in there, and requiring a big fancy session manager to actually do all
of this. In the process nothing has been won.

Nobody ever got fired for using hierarchical directory structures with
files in them. KISS.

-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 08:15:01 2012