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 lac2...@koln
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
rn...@rncbc.org
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Reply via email to