[LAD] Summercode 2008: LASH as a D-Bus service

[Bob Ham]

On Tue, 2008-01-22 at 20:40 +0200, Juuso Alasuutari wrote:
> On Tuesday 22 January 2008 19:18:10 Nedko Arnaudov wrote:
> > Juuso Alasuutari <juuso.alasuutari at gmail.com> writes:

> > > This is where I believe we both agree that turning LASH into a D-Bus
> > > service will help. The session handler shouldn't be a JACK client;
> > > instead, the audio server should be a D-Bus client of the session
> > > handler, although a Very Special one. And that's something that the JACK
> > > D-Bus control interface will enable.

I don't think this is necessary, or the right way to do it.  All LASH
needs is a way to determine which JACK (or ALSA seq, etc) client
corresponds to which LASH client, how they are interconnected, and a way
to connect different clients together.  These APIs exist already,
they're well defined and many applications use them.  It's also a little
presumptuous to assume that LASH will be the only program that would
require such functionality.

So I'm not sure what benefit adding LASH support to jackd et al would
have.  The best way to have the patch connection system as a D-Bus LASH
client would be to implement a bridge that interfaces with the existing
patch system APIs on one side and the LASH server on the other.  In
which case, why bother with a bridge at all?  You end up back with LASH
supporting the patch connection system, instead of the other way round.

> > Yes, except that I was thinking about not trating JACK server as LASH
> > client. Instead LASH should directly support and have special handling
> > of JACK server.
> 
> I didn't mean that JACK would be just another ordinary client for LASH; lashd 
> would naturally have special handling for it. Lashd would communicate with 
> jackd using the D-Bus interface that we're working on now. What I did mean 
> was that lashd shouldn't be a "JACK client" in the usual sense of the word 
> anymore, i.e. no libjack dependency. I believe this is what you meant also?
> 
> (I can see now as I'm writing this that Bob Ham is expressing a different 
> opinion on the list, maybe he'd like to comment on this further?)

Indeed, LASH already does have special handling of the JACK server.  Too
much special handling, in fact, as some API functions have the word
"jack" in them, which is just bad.

The only thing that JACK-DBus changes from LASH's perspective is that it
would need to make different calls to create port connections and to
register its interest in graph changes.  This isn't a big problem.

Bob

-- 
Bob Ham <rah at bash.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20080122/1046c7d5/attachment.pgp>