Re: [LAD] Non Session Management

I'm trying to figure out different use cases:

- an app loads an audio file (reference to orig file)

---possibility: file moves -> ref. has to be adjusted

- the app is non-destructive, for changes, a copy is produced (where?)

- the session is being duplicated - the new session keeps the refs to
original audio files, (but creates copies, for files which have been
modified ?? or refer.s them too ? refs. them too, I suggest. )

The problem here is, that files could quickly distribute (and
cross-link) over MANY different directories. Maybe a common directory
for all audio-files modified by ANY session-capable application
instead ?
pros: For all instances, we knew at least their files location.
Different instances could link to the same file (creating a new copy,
only when modifying)

Either way:
- There has to be a method to quickly find (maybe even auto-search)
files to fix defect links and re-assign paths.

- modified (thus copied) files have to be stored anywhere. (what about
a common directory ?)

-at least for exportation, there should be a method to transform all
references to actual files within (a copy of) the instances project
directory, allowing a package-of-all-related-files valid at a certain
time (state) to easily become created.

- a function called ...
create_file_export_for_current_state__copy_refs_to_real_files

- in the instances project dir, there should be a list of all related
(external) references (as Fons suggsted)
  For the SM to be aware of this list and its format, maybe it should
become a fixed part of the API !?

- the SM could provide methods to scan for missing references and
allow (the user) to fix them

Am 26. März 2012 23:40 schrieb Fons Adriaensen <fons@linuxaudio.org>:
> On Mon, Mar 26, 2012 at 10:32:38PM +0200, Emanuel Rumpf wrote:
>
>> - where would audio apps store large (audio) files ? a custom path ?
>
> That is something that needs to be looked at.
>

> An app can always cheat the SM.
But it is not allowed to - educate it to follow the law ;)

> Even if the SM forbids symbolic links in a session directory
It should proscribe that.

> all it takes for an app is saving
> a directory path as part of the current configuration.
>
right a path - a reference
but what about modified/copied files? (see above)

> But it would be better if the SM were aware of the existence
> of such data,
yes

> so that it could e.g. show a list of it upon
> request.
> This would then require apps to explicitly declare
> paths to external data. It would probably be a rather simple
> extension to NSM.
>
And a very useful one, improving integrity.

-- 
E.R.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev