22 Jan
2008
22 Jan
'08
2:40 p.m.
On Tuesday 22 January 2008 19:18:10 Nedko Arnaudov wrote:
Hmm, I think I went too far with ideas about clients being auto-launched by
D-Bus. It would add complexity, demand that the clients register as services,
etc. And what a horrible mess it would be to try to launch more than one
instance of a client...
So if we don't have to change the way autolaunching happens now, things are as
simple as Bob Ham put it in his reply: just point stdout/err to a log file
after fork()'ing. That would be accomplished with a rather simple patch.
Yes, except that I was thinking about not trating JACK server as LASH
client. Instead LASH should directly support and have special handling
of JACK server.
I didn't mean that JACK would be just another ordinary client for LASH; lashd
would naturally have special handling for it. Lashd would communicate with
jackd using the D-Bus interface that we're working on now. What I did mean
was that lashd shouldn't be a "JACK client" in the usual sense of the word
anymore, i.e. no libjack dependency. I believe this is what you meant also?
(I can see now as I'm writing this that Bob Ham is expressing a different
opinion on the list, maybe he'd like to comment on this further?)
What are they? :)
We're discussing them now. :)
Right. But introducing D-Bus and all that it entails into the soup will
complicate things if the first priority is to keep the API identical.
For instance, a client which communicates LASH events via D-Bus will need a
D-Bus event loop. Let's say we implement a completely transparent D-Bus event
loop into liblash which is launched by lashdriver_init(). Now, if the client
wants to manage other various D-Bus connections on its own, there will be two
event loops running within the same process.
If a client wants to handle its LASH events using QtDBus or DBus-GLib then
lashdriver_init() shouldn't try to handle everything. And on the other hand,
I'd be happy to use a library which provides a D-Bus event loop and event
handling for LASH clients, instead of having to write one from scratch.
Juuso
Juuso Alasuutari <juuso.alasuutari(a)gmail.com>
writes:
<snip>
Idiot-proof
capturing of stdout/err could probably only work if the
client process was executed from a wrapper. It could be accomplished with
the D-Bus service file, though. If all clients' service files would be
mandated to include something like "Exec=/usr/bin/lash_exec
/usr/bin/foobar", then... Umm, at least we could redirect the streams
_somewhere_ -- but what to do from thereon, I'm not sure.
I was thinking about "sending" client stdout/stderror to log file (with
prefixing). I dont think we need to require registering of one dbus
service per lashified client (autolaunching). Also IMHO there is nothing
wrong with just capturing stdout/stderr of launched clients. Of course,
liblash (dbus version) will start lash service to provide "callbacks" for
the lash API. * lash is of mercy of libjack and crashing jackd
often causes lashd
kill. This is just wrong. lash should be able to restart jack, tell
jack apps that jack server is started again so they can reconnect to
jack server and finally lash can restore jack connections.
* lash should preserve at least basic properties of currently started
JACK server, such as sample rate and availability of hardware
ports. When loading session whose JACK parameters dont match, user
should be given options what to do.
This is where I believe we both agree that turning LASH into a D-Bus
service will help. The session handler shouldn't be a JACK client;
instead, the audio server should be a D-Bus client of the session
handler, although a Very Special one. And that's something that the JACK
D-Bus control interface will enable. * there is no export/import "tarball"
(single file) functionality, to
be used for backup of sessions and transfering them between machines
* lash apps should be allowed to do "light save", with app session
referecencing files/resources external to lash. This means for
example that such lash light save should not copy ardour wav files
that are linked (not copied) to lash directory.
These sound like they could be useful features. However, I feel that we
should settle on the more basic issues first. At this point
I believe it would help to categorize the different
sub-goals. What issues are purely in the domain of API design, what are
the things that the daemon must handle, etc. I'll start sketching these
and getting familiar with what we have now, then post some sort of rough
draft. In the meantime I'll be happy if anyone wants to comment on the
questions above.
If you are talking about the liblash API, I'm oposed to breaking
it. OTOH, I think we could extend it or provide alternative API. We dont
need to kill lash pupil apps, right? :)