[LAD] LADI

[Gabriel M. Beddingfield]

On Tue, 22 Dec 2009, Patrick Shirkey wrote:

> So you agree with Fon's statement that if the jack_session code is
> accepted you would not want to use jack1 any longer and would support a
> fork or stop using it completely and create your own realtime audio daemon?

Probably about as much as you agree with Stéphane's threat 
to do the same over dbus (which, IIRC, is closely related to 
the session management debates). :-)

> I must have missed the part of the debate where it was agreed or even
> defined that jack_session would not be able to play nicely with more

Here's a few with the most recent proposal:

* save/restore requires application to shut down and
   restart.

* session callback does not work asynchronously

* process call graph must be halted during the
   session callback (a consequence of not being
   asynchronous).

Also, I wasn't comfortable with how the serialization should 
work... but it was too early in the process to pick nits on 
that.

> As far as I can tell the design process broke down mostly because one
> person made a strong case for not having any other form of session
> management except the one that he is working on (and is now saying he is
> not interested in releasing publicly) and consequently wound the other
> parties up to the point where they decided it was too frustrating or
> stressful to discuss it any further at that point.

Once it's in the JACK API, it won't be coming out. 
Likewise, changing it will be very difficult after the 
fact... so it needs to be right.

If it's not in the JACK API, there is no argument.

-gabriel