25 Jan
2008
25 Jan
'08
8:04 a.m.
On Wednesday 23 January 2008 23:21:21 Bob Ham wrote:
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.
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).
Can you explain this?
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? 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. 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 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