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

On Thu, 2008-01-24 at 05:33 +0200, Nedko Arnaudov wrote:
> Bob Ham <rah@email-addr-hidden> 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@email-addr-hidden> 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@email-addr-hidden>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev