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

[Nedko Arnaudov]

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?
>> >
>> > A good example.  What does the watchdog do, exactly?  It isn't a
>> > frontend.  I doesn't try to work around jackd's crashing.  It just
>> > ensures that if something bad does happen, the computer as a whole isn't
>> > brought down.  This is massively different from what you're proposing.
>> >
>> > 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 :-)  As I understand it, the issue is that jackd crashes,
> and when it does it tends to bring down the whole audio session which is
> a nightmare from a usability perspective.  Nedko's proposal is to create
> some system outside of jackd that can account for those crashes and
> maintain the audio session in spite of them.
>
> I think this is wrong.  It's saying "OK, jackd isn't robust and we're
> going to take account of that in our JACK-dependent system" when what
> should be said is "OK, jackd isn't robust so we're going to make it
> robust."

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

>> > A layer that abstracts away the incidental
>> > obligations of being a JACK client would be good but that is very far
>> > from the domain that LASH is intended to help with.
>> 
>> If such a layer could be beneficial (which is my belief also), why do you 
>> think that it's outside the scope of LASH planned improvements?
>
> There's no reason to add a system-specific API layer to LASH itself.
> The abstraction could be done by a separate library entirely, eg
> libeasyjack.

We are talking different dialects here.

>> > 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. Again, this is how
it *can* be shown to user. I perfectly know how LASH approach is different
From a real all-in-one app. And I personally want separate control
app. I.e. patchage for patchbay app, wmglashctl for control app. But I'm
sure most WIMP addicted ppl will like Patchage to behave as lash control
app. And IMHO, this it is a good feature to include in Patchage.

>> > It seems that what you want is Patchage++.  Unfortunately, LASH isn't
>> > that and I think you're likely to run into problems if you try and turn
>> > it into that.
>> 
>> Yes, at least I would like to see the day when one application can manage 
>> everything that the concept of an "audio session" includes (Patchage is 
>> probably pretty good already). But you've misunderstood the purpose of this 
>> discussion. We're not out to turn LASH into a super daemon/application of the 
>> sort that you're worried about. What we are trying to do is to think of how 
>> the interfaces and features of LASH could better help support a controller 
>> application's operation.

yes, no super-daemon, but just LASH serving better. How? We are
discussing that.

> The thing is, a lot of the problems that have been highlighted as
> capable of being solved by LASH aren't really anything in LASH's domain
> and *shouldn't* be solved by it.
>
> For example, yes, you could add support for maintaining the specific
> settings of the patch system (I'm referring not just to JACK here) but
> that's not what LASH is concerned with.  It only cares about patch
> configurations and client state.  If it's the case that LASH *has* to
> control the settings of the patch system just to provide a usable
> system, then it points to a problem with the patch system.  If the user
> wants to change settings on the fly then the patch system itself should
> enable that.
>
> 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.  Here is the list of future LASH
> work from a while back:
>
> 	1.0
> 		Client priorities
> 		Track naming
> 		Guaranteed save directory availability
> 	>1.0
> 		Graded saves
> 		Networked audio
> 		User interface standard
> 		Automatic client installation
>
> And I would add to that now:
>
> 	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++

It is quite obvious that we have different plans for "LASH". As for used
technologies, IMHO, this should be driven by people acutally commited to
writing and maintaing the code (ATM this means almost nobody). If it me
to decide, I'd probably use python dbus service as replacement for lashd.

Some thoughts regarding your 0.6 wishes:

UDP OSC is one of the evils of current implementation. It fails to work
if networking is not properly set. If you dont beleive me - ask
users. OTOH I'm probably one who strives for dbus lash (as lash app -
lash "daemon protocol) at smallest degree (Dave, Juuso). D-Bus is quite
useful, especially its service autolaunching feature, high level of
object interface abstraction and easy integration with high level
scripting languages like Python.

certificates? encryption? really? For 0.6? o.0
Overengeneering?
Probably has to do with your conquer the network plans. I'm not oposed
(network), but I dont think this is that much important ATM.

I dont think using gobject is good thing in this case, because of the
KDE/GNOME schism. It is a political issue - IMHO using gnome component
will restrict KDE adoption. I dislike the schism but unless we get
freedesktop.org object model, we are fscked to reimplement things from
scratch for things like jack, lash and slv2.

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.

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20080124/e2c03b73/attachment.pgp>