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

[Bob Ham]

On Thu, 2008-01-24 at 05:33 +0200, Nedko Arnaudov wrote:
> Bob Ham <rah at bash.sh> writes:
> 
> > On Wed, 2008-01-23 at 19:44 +0200, Juuso Alasuutari wrote:
> >> I'm getting the feeling that there have been some misunderstandings in this 
> >> discussion. Let's see if I can help with them, or if I'll just end up 
> >> confusing things more. :)
> >> 
> >> On Wednesday 23 January 2008 00:18:48 Bob Ham wrote:
> >> > On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov wrote:
> >> > > Bob Ham <rah at bash.sh> writes:
> >> > > > More generally, LASH isn't a frontend for JACK.
> >> > >
> >> > > What about the jack watchdog? What does get killed by it?
> >> > To try and work around a crash in jackd and present a system to the user

> >> > where crashes make no difference is to invite more problems.  If you
> >> > can't get jackd to stay up, what makes you think you can get your new
> >> > system to stay up?

> >> 
> >> I don't think Nedko's proposal is motivated by a desire to work around 
> >> existing bugs.
> >
> > It sounded suspiciously to me as though that was exactly what Nedko's
> > proposal was :-)

> IMHO, jack watchdog is feature, not bug. And yes, LASH needs a way to
> handle it.

Of course it needs to handle it.  It needs to cleanly shut down due to
the catastrophic failure.  That's very different from creating a layer
betwen JACK and the LASH clients where the catastrophic failure is
glossed over.

> >> > To view LASH as the centre of a linux audio system is to misunderstand
> >> > its purpose.  It might be able to *facilitate* a unified system, along
> >> > with JACK and other APIs, but it isn't the unified system itself.  Such
> >> > a role is intended for the much-loathed "server interface" distinguished
> >> > in the LASH API.
> >> 
> >> I personally don't see LASH as the centre of the audio system, and I'm not 
> >> sure that Nedko meant to say that either.
> >
> > I must have been thrown off by Nedko's words "LASH should behave like
> > all-in-one app" ;-)
> 
> From user perspective, yes. lash + patchage like app.

Well, more accurately it would be patchage-like-app + lash + jack + alsa
+ x11 and, if you're going to get networking in on the game, + ssh.  You
can see that lash is just a small part of such a system.  The key issue
becomes the patchage-like-app.

> > IMHO, there is a lot of work to be done to properly provide the kind of
> > support that LASH is *trying* to provide, without going on and thinking
> > about what else it might be able to do.

> > 	0.6
> > 		Redesign client/server communication
> > 			Certificate based security/encryption
> > 			Use OSC
> > 		Rework API
> > 			Genericify patch-system specifics
> > 			Provide more useful event system (callbacks, etc)
> > 		Rewrite client library in gobject
> > 		Rewrite server in C++

> Some thoughts regarding your 0.6 wishes:
> 
> UDP OSC is one of the evils of current implementation.

Current implementation of what?  Regardless, the transport that's used
isn't particularly important; you can just use TCP if UDP is an issue.
Or fix the UDP transport.

> certificates? encryption? really? For 0.6? o.0
> Overengeneering?

Possibly.  However, I think it's a good idea to have it included at the
start of any redesign of the communication system.

> I dont think using gobject is good thing in this case, because of the
> KDE/GNOME schism.

Just because the library is written using gobject, doesn't mean clients
have to be.  It's now trivial to run a QT main loop and glib main loop
together:

  http://developer.kde.org/documentation/tutorials/qtgtk/main.html

> I do agree about "Provide more useful event system (callbacks,
> etc)". However, it is important not to break current API, but extend it
> or provide alternative API. I also agree with Juuso, that fixing the API
> can (and probably will) be made after we fix the more important things.

I think it's important *to* break the current API due to its many
issues.  Why do you think that backwards compatibility with the current
API is important?  

Bob

-- 
Bob Ham <rah at bash.sh>