Re: [LAD] LADI

From: Rui Nuno Capela <rncbc@email-addr-hidden>
Date: Sat Nov 21 2009 - 17:36:56 EET

On 11/21/2009 02:47 PM, Patrick Shirkey wrote:
>
> 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.
>

first time i've heard of the ladi effort was in the lac2007@email-addr-hidden
cafeteria. is there an old conspiracy or has dan brown already picked up
the lads as subjects? nevermind, i've been m.i.a. too many times :)

> 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?
>

please note, i've meant the establishment of the so called *jack control
api* iow, libjackcontrol.so.

i really don't care whether that jack-control-api is actually
implemented through dbus, osc or whatever-ipc, but it must be
established enough as the official way to control jack. qjackctl, as i
know it, is only going through that jack-control-api and *not* dbus,
osc, whatever.

> 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.
>

of course.

byee

-- 
rncbc aka Rui Nuno Capela
rncbc@email-addr-hidden
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sat Nov 21 20:15:03 2009

This archive was generated by hypermail 2.1.8 : Sat Nov 21 2009 - 20:15:03 EET