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

On Wednesday 23 January 2008 23:21:21 Bob Ham wrote:
> > > 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.

By "system-specific API layer" do you mean D-Bus? And do you
say "system-specific" as opposed to "also connects between networked
computers"?

To me, it seems like overengineering to design the LASH <-> client protocol
with networks in mind. The lashd daemon can use D-Bus to communicate with
clients, but that doesn't mean that several LASH daemons running on different
computers couldn't communicate session events and data between eachother. The
idea would be that all LASH <-> client connections would be local, but one
session could be composed of several local LASH environments.

> > > 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.
>
> 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.

Yes, I suppose that the patch system settings for a session could be handled
by a dedicated patch system controller (e.g. QJackCtl), which would itself
just be a normal LASH client within the session. And when you would load a
saved session, the patch system controller would fire up and adjust the patch
system settings. LASH wouldn't care about its doings.

But then again, why should LASH even be concerned with the connections between
clients in the first place? Why doesn't LASH just start the clients, tell
them to load their settings, and leave the other stuff to a patch system
controller?

You probably noticed that the question was rhetorical. My point is: Where is
it precisely defined what LASH's domain is? Where does this reasoning and
concept model come from? I've gotten the feeling that this distinction that
you maintain between LASH and the rest of the system is nothing but a
tradition.

Extending LASH's domain to include not only the client state and their mutual
connections, but also the sound server configuration, is not conceptually
invalid although it may not be what LASH was originally _thought_ as. It may
not be a requirement for a usable system, but it does make things more
convenient for the users (and probably for the developers as well).

> 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:

I'm afraid I don't understand all of the things you mention below, probably
because there's hardly any descriptions there.

> 1.0
> Client priorities

Can you explain what you mean by this?

> Track naming

And this?

> Guaranteed save directory availability

Does this simply mean that lashd will somehow make extra sure that the
directory exists, and that the client can write there? If so, it sounds good.

> >1.0
>
> Graded saves

Can you explain this?

> Networked audio

And this?

> User interface standard

And this?

> Automatic client installation

This sounds an awful lot like stepping on the toes of packagers and package
managers. Unless you mean something completely different, of course.

>
> And I would add to that now:
>
> 0.6
> Redesign client/server communication
> Certificate based security/encryption

Why would managing an audio session demand that the connections be certified
and encrypted? Unless you're thinking network-wise (i.e. sessions that span
several networked computers).

By the way, did you know that D-Bus allows security policies?

> Use OSC
> Rework API
> Genericify patch-system specifics
> Provide more useful event system (callbacks, etc)

I think that an API overhaul would be welcome, and especially using callbacks
would be an improvement. But it's not first priority (thought not the lowest
either).

> Rewrite client library in gobject
> Rewrite server in C++

These sent a cold shiver down my spine... mostly because I don't know C++ and
I'm unwilling to learn it right now. :)

I've looked at the LASH code, and I must say it looks very well written.
You've done a great job. I don't see any reason why the current codebase
would need an overhaul. How do you feel that a rewrite in C++ would help LASH
as a project?

And about GObject... well, why bother? I understood from your reply to Nedko
that you're not suggesting that GObject be enforced into the actual LASH API,
which is a relief. I fail to see any benefit in GObject-ifying the internals,
either.

Juuso
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Jan 25 16:15:03 2008