On Friday 25 January 2008 18:27:10 Bob Ham wrote:
Why bother with a long-reaching workaround like that? I understood this
hypothetical "libeasyjack" to be something that would enable a program to be
a JACK (libjack) client without actually having to fulfill the requirement of
running with RT priority. But for our needs (setting connections, getting
connection info, etc.) it's simply backwards to stubbornly hold on to keeping
LASH a JACK client. There's a conceptually saner solution around the corner.
The goal of jackdbus has never been to shield applications from JACK's bugs,
and I regret that this conversation has revolved around that side effect for
so long. Jackdbus allows more flexible controlling of JACK settings in a
desktop environment, by desktop applications. Implementing this kind of
interface makes sense for more than one reason.
It's not about "adding a system-specific API layer to LASH", it's about making
use of an API layer in LASH because it fits the purpose well.
> > To me, it seems like overengineering to design the LASH <-> client
For domain separation this makes sense. Why add weight to the the LASH <->
client protocol with things such as encryption which most users will never
Don't get me wrong; inter-host communication is a great idea (for future
implementation). But I think a local session protocol should be minimally
burdened by the needs of a minority. Yet this is not the only reason I'm
against a "lashd <-> the entire world" client protocol. Consider the
If your session is spread across multiple networked computers, how will you be
able to auto-launch all the clients if there are no per-host daemons
involved? In other words, your master lashd can launch all the clients on the
master host, but if you also want to launch remote clients you will need some
kind of launcher daemon running on the remote computers.
If there's a lashd running on each computer, the master lashd can tell the
slave lashds to auto-launch their clients. It seems to me that adding this
lashd-to-lashd layer between local domains is both friendlier for clients in
terms of protocol complexity and also enables better control.
> > But then again, why should LASH even be concerned with the connections
OK, I see. :)
> There's three different ideas that could be surmised by "patch system
That reasoning seems solid, thanks for taking the time to explain.
I can imagine how the session could be comprised of:
- LASH which only manages client settings and connections,
- normal LASH clients, and
- a JACK controller, which is basically a normal LASH client.
And I can imagine how the session loading could happen approximately like
- LASH launches the JACK controller app,
- the JACK controller app modifies JACK settings and possibly restarts JACK if
- LASH launches the rest of the clients,
- LASH connects the ports between the clients.
I'm still not sure that this would be the most convenient solution for
everyone involved. Would it mean significantly more work for control
application/frontend coders? Would it be more confusing for the users? I'm
hoping that someone could comment on this.
Now imagine the above scenario, but imagine that the JACK controller app
doesn't get launched first. It will potentially wreck the session if it
restarts JACK after other clients have loaded. If controlling JACK settings
is done by one of the session clients, should that client be able to register
to LASH with a special flag which indicates that it should launch first?
> > > Client priorities
Good idea, I agree.
I'm not sure that this level of session management is necessary for LASH. But
it may very well be that I'm still not getting the point.
> > > Guaranteed save directory availability
Perhaps lashd could monitor the current save dir via FAM and at least produce
a warning if it gets deleted. But that's more of a tweak than a feature.
How about if a guaranteed directory would be the default? The clients would
receive a directory name (and could also ask for it later if they have a
short memory or something), and it would be guaranteed to exist unless a
special "directory has changed" message has arrived.
Therefore the usual save command wouldn't be "save to $dir", but rather "save
to the dir that i gave you during init". Only special save commands
like "export all data to $outside_dir" would include the dir name with the
> > > >1.0
I don't get this. But sounds like what's been talked about on #lad: Different
save types like "normal save", "light save", "export"...
> > > Networked audio
OK, sounds like a reasonable long-term goal.
> > > User interface standard
You're treading on flammable ground here. I wouldn't want LASH to have the
slightest authority over what toolkits and/or widgets the clients are coded
with. And I don't see any reason why LASH should even care; LASH isn't a
plugin host. I should be able to include an Ncurses-based drum machine with
my session if I please.
> > > Automatic client installation
Yes, you are stepping on packagers' toes here -- heavily.
Abstracting package management for distros is an insanely huge task, and not
likely to work in practice. Creating an automatic compilation environment --
well, I assume you're joking, because this would equal writing your own
source-based package manager. Using autopackage is out of the question,
because you simply can't fulfill the needs of all distros even with such a
system. (No, rpm and deb aren't the entire universe.)
If a session manager would take on package management like this -- which it
definitely _shouldn't_ in the first place -- it would have to work absolutely
_perfectly_ on _all_ possible distros. Either that, or nothing.
I'm a packager myself, for a smallish source-based distro called Source Mage.
The way our package manager works is likely to be incompatible with any other
system. I wouldn't want autopackage messing around with my box -- I want
packages installed the way they normally are with Source Mage.
Considering how you've been defending LASH from features that you deem outside
of its domain, I'm surprised that you would come up with this idea.
There is something I could think of, though. Maybe LASH clients could register
a homepage URL or equivalent piece of information which would help the user
to hunt down the missing program in case he/she needs to? That's about as far
as I'd go along that path.
> > > And I would add to that now:
As I've said before, I don't believe it's a good idea to add this stuff to the
client protocol. Inter-host communication is a different thing.
> > > Rework API
I can understand your point. It may well be that fixing the API takes
precedence over much of the other changes.
> > > Rewrite client library in gobject
Yes, personal preference, we meet again. :)
> > And about GObject... well, why bother? I understood from your reply to
Well, whoever writes the code gets to decide I guess.
Linux-audio-dev mailing list