21 Nov
2009
21 Nov
'09
11:36 a.m.
On 11/21/2009 02:47 PM, Patrick Shirkey wrote:
On 11/21/2009 10:13 PM, Rui Nuno Capela wrote:
first time i've heard of the ladi effort was in the lac2007@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 :)
On 11/21/2009 05:18 AM, Patrick Shirkey wrote:
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.
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 ;)
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(a)rncbc.org