On Tue, 22 Dec 2009, torbenh wrote:
>> Also, I wasn't comfortable with how the serialization should work...
Two links (requires jack-devel list authentication):
I really think there should be a quit-without-save.
Also, with respect to saving and restoring sessions,
suppose this work-flow:
1. Save a session (#1) with Ardour as a part of it.
Instead of transferring GB of data to the
session-data-dir, it stores a handle to the
data (i.e. a URI tracing back to a save state).
2. When session #1 is reloaded, Ardour loads the
handle to the original project's save state.
3. User forces an export to the session-data-dir.
This means that Ardour must transfer all the
gigabytes of data necc. to recreate the session.
4. User opens session #1 from an exported archive.
Ardour finds heavy data in the session-data-dir,
and uses it (rather than, say, importing the
data to some other location).
5. User does a "save as" on the current session,
thus saving Session #2. Ardour saves a handle to
a save-state from Session #1 (and Session #1's
6. User deletes Session #1. They now
have also corrupted Session #2.
This just seems, to me, messy and error-prone. To the end
user, I don't think it would ever be obvious that Session #2
depended on Session #1. Meanwhile application developers
have to find a stable way to work with session data, whether
it's handles or heavy data. They also have to negotiate
what it means when the user says "Save," but the data is in
a session-data-dir, and the user /didn't/ say "Save
Ways that it might be cleaned up:
1. Always require that session data be "heavy"
in the session-data-dir.
- or -
2. Only store handles to session data... and
don't even have a session-data-dir. Export
is a special step. Exported sessions must be
"imported" before being used.
- or -
3. Session manager implements some manner of
"session data database" that manages the
dependencies between resources and sessions.
Applications transfer data to session manager
as something like a zip stream... and the session
manager is responsible for storage and retrieval.
#1 is, I think, the most stable... but at the price of
wasting a lot of disk space. #2 is fast and efficient, but
at a much greater risk of corrupting session data. #3 is
like #1, but the session manager implementation is able to
conserve resources and even be on another host.
 In my e-mail in November, I used the word "stub"
instead of "handle."
 Yes, this idea is a little "out there." :-)
Linux-audio-dev mailing list