21 Dec
2009
21 Dec
'09
6:55 p.m.
On 12/22/2009 12:39 AM, Gabriel M. Beddingfield wrote:
On Mon, 21 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?
While Fons is thorough with his criticism which is to be respected as it
helps to refine the knowledge base and code, that should not mean that
the option of having jack_session available for the rest of us to use is
completely off the table. We just need to be aware of the limitations.
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
advanced managers. In fact Nedko even offered his support/interest for
making LADI work with jack_session. Being that LADI is real and publicly
released that should hold more weight than Fon's views on the matter.
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.
Patrick Shirkey
Boost Hardware Ltd
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
[snip]
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
I recall a few people agreeing with Fons. Plus, Fons is so frigging
thorough that... what should we write? "Yeah!! What he said!" Hardly
an important contribution to the discussion.
Also, with the reception that Fons got, I'm sure there were a few like
me who kept their mouths shut unless they had something important to
contribute.
Anyway, FWIW, I agreed 100% with Fons... and IIRC he was open to
having an in-JACK session management API provided that it played nice
with a larger, more comprehensive session manager. (I.e. partial
session loading/saving, no client renaming, etc.)