22 Jan
2008
22 Jan
'08
1:13 p.m.
Juuso Alasuutari <juuso.alasuutari(a)gmail.com> writes:
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.
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.
What are they? :)
*
auto-launching without logfile means no proper handling of lashified
apps stdout/stderr. It should have logfile, with prefixing output of
apps.
Capturing the clients' debug messages would indeed be helpful. How do you
think it should be handled?
One option would be to add a logging method to the API that the clients should
use. But as with most other client requirements, there's no way to control
that they actually behave correctly (think of loading and saving files
correctly). And even if they do, then what about other messages than those
deliberately put into the code, like e.g. GLib errors?
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. * 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? :)
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>