All:
Based on some of the recent discussions on LAD and LAU, I
thought it prudent to forward this message from the
Jack-Devel list.
If you wish to continue the discussion on the the Jack
session management API, please do it on the Jack-Devel list.
Scroll down to the very bottom for a URL to the list.
-gabriel
---------- Forwarded message ----------
Date: Thu, 4 Mar 2010 18:16:39 -0500
From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
To: jack-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Jack-Devel] session management API proposal, take 3
[ ... chatter chatter chatter ... ]
i'm on the verge of approving the API proposed by Torben for inclusion
as part of the JACK API. I believe that it accomplishes the goal of
leveraging an existing IPC channel (via libjack), combined with a
minimalistic set of changes to the server and easy-to-implement
support in clients, to provide the basis for session management at
different levels of sophistication, depending on a user's needs.
Torben's example showed the generation of a shell script that will
restart the session, and this is probably the "bottom line" in terms
of simple session management.
There are still some details (below) but more importantly, I would
like to hear from people who have concrete objections, particularly of
the following form:
* the proposal does not address some functionality that it should address
* the proposal will make later, more extensive session management
harder, more complex or impossible
* the proposal is nonsensical because ...
As for details...
I agree with the suggestion that the initial set of session events
should include "quit".
Nedko has also raised some objections to the use of a UUID, and has
proposed a scheme based on PIDs. I personally do not understand how
this can possibly work if JACK is to retain the ability to support
multiple clients per process. Any scheme designed to use PIDs but
still allow this seems to me to have to turn the PID into a UUID by
combining it with some other information (eg. a client name). This
doesn't seem to be semantically different from starting with a
declaration that we use UUIDs to identify clients - how the UUIDs are
constructed is an implementation detail.
Finally, the semantics of the return codes from a session event need
to be pinned down better, since there are circumstances where a client
could *not* save its state without that being an error (e.g. ardour
running with a session on read-only media). For this, I currently
propose:
success == client believes that it will be able to restore its
state to the current state upon a reload
fail = client believes that it will not (or may not) be able to
restore its state to the current state upon a reload
similar semantics will be needed for each other defined session event.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@xxxxxxxxxxxxxxxxxxx
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
