Re: [LAU] What are we talking about. (Was: KILL DBUS)

Marc,
Thanks, and a great user oriented explanation.
I'm also mindful of the considerable work being done with the LADI
tools, and the testing i enjoyed doing last year.

Just to be clear here, i still can't see the need for an additional
layer of 'complication' (don't forget i'm just a user, not a coder.),
but i'll continue to be open minded about the progress. The old Jackd
is definitely my comfort zone, and it would true to say, that anything
that upsets that stability starts me asking questions.

Thanks again, i just learned something, whether i agree with it
currently, or not.

Alex.

On Mon, May 18, 2009 at 6:25 PM, MarcO'Chapeau <marco@email-addr-hidden> wrote:
> On Mon, 18 May 2009 17:36:11 +0400, alex stone <compose59@email-addr-hidden> wrote:
>> Marc,
>> hehe, and the waltz continues. So let's assume that pulse isn't being
>> considered here as part of the dbus paradigm intent .
>
> Hi again.
>
> Ok, let's stop dancing then :) Let me try to explain that dbus here is not
> the center of what has changed in JACK2.
>
> The new feature in JACK2 is the control API. That is: a *C control API*.
> Now it is very important to read the previous sentence over and over again.
> Once the dbus keyword has disappeared of your focus, read on.
>
> So, this C/C++ control API allows one to start/stop jack, configure it, and
> manage connections in between clients. This C control API allows one to
> control the server entirely in a cleaner fashion than what was used before.
> jackd makes use of this new API.
>
> And now the fun part. Say we want to control JACK with hmm... OSC. One will
> program something called jackosc that will *expose* the jack control API
> through a small OSC server. it's as simple as some python bindings for
> instance.
>
> Now that I have explained most of the new stuff in JACK2, back to our
> issue. jackdbus is just like what I described with jackosc, except that
> instead of *exposing the C API* through an OSC interface, we do that
> through a DBUS interface.
>
>> Is there going to be a non dbus jack version going forward?
> You should already have the answer : there is and there will always be. The
> JACK control API is the core and is C, dbus is just an interface, just like
> any other kind of interface would be (OSC, HTTP, whatever...).
>
>> And please assume here i'm talking about a complete
>> non dbus version, not a compile time option to disable it.
> So you want to have 2 separate versions maintained ? One with a control API
> and no interfaces other than plain C and one with interfaces included ?
> Because if it's not a compile time option, I don't see what else it could
> be.
>
> Who wants to maintain to trees just to hide a compile time option ? what if
> we really add jackosc to the list ? Should that be a third tree ?
>
> Nedko, Stéphane: If I made any mistakes in my explanations, please correct
> me :)
>
> Marc-Olivier Barre.
> ------
> Participez au black-out anti-HADOPI :
> http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>

-- 
Parchment Studios (It started as a joke...)
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user