[LAD] Non Session Management

[Emanuel Rumpf]

Am 27. März 2012 03:23 schrieb David Robillard <d at 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 feel that symlinks pollute the file-system
- What if any of the symlink to symlink is deleted - do applications
still know, where the file is which they had been pointing too ?
- Some apps would want to store additional info relating to the file
(meta-data, tags, related info, ...), thus requiring a simple database
anyway.
- 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

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 ??
I think no. After modification, creation, duplication, etc.,   soon
you won't be able to say, weather a file is a any of the above. I
mean: For one app it can be a file (original), while for another it
can be a copy / reference / whatever.

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 !
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 ?


My conclusion:
- -
1. large files should never go to the session directory

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

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

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)

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.

7. The SM allows Lfiles (CURRENT_REF + EXTERNAL_REFS) for a certain
session or app to be copied to a user-defined directory
(export-function)

8. The SM allows HISTORY_FILES to be moved to a dustbin folder.  (not
including CURRENT_REFS or EXTERNALS)

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


-- 
E.R.