On 11/21/2009 10:13 PM, Rui Nuno Capela wrote: > On 11/21/2009 05:18 AM, Patrick Shirkey wrote: > >> One major item of note is that qjackctl now has preliminary dbus support >> even though Rui has stated that it would not happen. This step in itself >> should be clear a major roadblock to LADI integration and deployment. >> >> > wait, i don't seem to remember having said it would *not* happen. i > think i had said it would be *hard* to happen, mainly due to my > everlasting lack of time. you all know the stance ;) > > and moving on a bit (but staying in the same place): > > i think a also made my position long ago that qjackctl is a jack control > application and thus, it should harness the jack control api and nothing > else on the side. imo, it's this jack control api or protocol that > should be implemented through whatever ipc mechanism you think of (dbus, > osc, yada yada). > > ok, in that sense, you can say that qackctl would not go the jack dbus > route, at least directly face to face. again imo, it must do it on top a > an established jack control interface. no more no less ;) > >
LADI represents a very powerful and flexible session management system that has been built on 7 years of intense debate/thinking/development and several competing and complimentary implementations. Qjackctl *is* the default desktop management interface for jack. It would be a very powerful combination if qjackctl supported the functionality provided by the LADI tools. Currently we have a chicken/egg situation as you are not prepared to spend your valuable time on session support until it is officially established but if the default management tool doesn't support the most flexible option we have available then how can it be considered established? If LADI which now represents a significant effort by several very clever and committed developers is not officially supported then we as a community are encouraging the fragmentation to continue rather than forging better integration. Supporting LADI doesn't mean that a non dbus solution can't be supported or that everyone has to be forced to use the dbus solution. Patrick Shirkey Boost Hardware Ltd _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev