Juuso Alasuutari <[EMAIL PROTECTED]> writes: >> * 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.
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. 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. >> * 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. What are they? :) > 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>
pgpb4dnoqQpmR.pgp
Description: PGP signature
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
