On 12/21/2009 08:45 PM, alex stone wrote:
Thinking back there was an agreement from Stephane and Torben that they
would not expect either to either work on jack_session for jack2.
However I don't recall Stephane explicitly stating that he had an
objection to jack_session being integrated into jack2. Simply that he
would not be the person to do it and that Torben didn't want to work
Given that the actual code proposed by Torben is incredibly simple
compared to the mental effort it took to come up with the implementation
I don't see how it will not be integrated into jack2 at some point in
the not too distant future.
I definitely don't recall Paul saying anything about it not being
accepted to jack1 trunk. I have assumed his lack of communication to be
tacit agreement that it is a viable addition to the codebase.
The only person I can recall who had an explicit objection to it was
Fons, who said he would stop using jack if it was accepted. Given that
Fons is doing some pretty custom stuff with the system that he runs and
is more than capable of contributing code that would disable
jack_session if it was not made a compile time option (which is is
anyway). I don't think he should be allowed to make the decision for
the rest of us about what is accepted to trunk and what is not. Also
considering that he is now suggesting that he will not even release his
version of session management I really have an objection to his
objection being given priority over the rest of us who support
jack_session as a viable option.
Unless there is something that I have missed over the passed two weeks,
I think it is time for a vote on the issue if there really is no
consensus between the major stakeholders.
As far as I can tell it boils down to this:
jack1. Torben has provided a test case and code for integration.
jack2. No one has offered to integrate Torbens work yet.
jack_session adds 4 or 5 additional callbacks to the code base. It
allows for simple session management to be handled within jack with
minimal code needed on the client side. It can be integrated with LADI
realtively easily and Nedko has offered his support for making that
happen. Additionally there is a potential for a new non realtime thread
to be added to the server for handling session requests to enable things
like undo and application renaming when loading sessions while an
existing session and/or app is running.
From a normal users perspective we would need to have an interface that
gave us the options:
- killing already running apps before loading a session
- attempting to rename the apps without restarting them
- load a new jack instance and connect it with netjack
I see this interface being similar to the firefox recover session
interface but others may think of better ways to handle/present the options.
Boost Hardware Ltd