27 Mar
2012
27 Mar
'12
2:24 p.m.
Am 27. März 2012 03:23 schrieb David Robillard <d(a)drobilla.net>et>:
... 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.